You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by Stefan Bodewig <bo...@apache.org> on 2011/08/10 17:38:50 UTC
Re: Compiling log4net with strong name and 3rd party dependencies
On 2011-08-08, Johannes Gustafsson wrote:
> There are a few bugfixes in the trunk that I need and since there has been
> no new release for a very long time, I tried to compile it myself. I created
> a key and have successfully compiled it with no problems. However, I have
> quite a few 3rd party dependencies that themselves are dependent on log4net.
> These dependencies can't find load the new assembly that I have created
> because they require that it is signed with a key that I dont have access
> to. So this means that I can't use my own version of log4net without
> recompiling all my dependencies.
> Do you have any suggestions to how I can solve this?
For your current situation I don't have one, sorry. Helping to get
log4net 1.2.11 released by verifying fixes might be an option ;-)
For future releases I'd suggest to take a different approach - and this
likely is a discussion point for the dev list. Therefore the
cross-post, please let us keep the discussion there.
I happen to be one of the ASF Incubator mentors for Lucene.NET and the
question of whether they should strong name their assembly at all and if
they should keep the signing key secret came up there for their last
release - well, they didn't really question it, I did.
Several people had good arguments towards strong naming - there are
deployment situations where it is simply necessary to use the GAC, think
BizTalk. And several people had good arguments to simply give the
signing key away to everyone, this would help you in your case.
This seems to be consensus by now by pretty much all Open Source
projects in the .NET space. Just hand out your signing key so people
can create their own patch builds - as they can do for any other
platform as well. There is absolutely zero security attached to that
key if used that way, but that doesn't matter since our releases are
signed using OpenPGP and we provide hashes of everything.
I'd propose to not keep the signing key of future releases secret but
simply keep the full keypair inside the source tree.
Stefan
Re: Compiling log4net with strong name and 3rd party dependencies
Posted by Jim Scott <js...@infoconex.com>.
-----Original Message-----
From: Stefan Bodewig
Sent: Wednesday, August 10, 2011 8:38 AM
I'd propose to not keep the signing key of future releases secret but
simply keep the full keypair inside the source tree.
Stefan
-----------------------
I second that!
Jim
Re: Compiling log4net with strong name and 3rd party dependencies
Posted by Jim Scott <js...@infoconex.com>.
-----Original Message-----
From: Stefan Bodewig
Sent: Wednesday, August 10, 2011 8:38 AM
I'd propose to not keep the signing key of future releases secret but
simply keep the full keypair inside the source tree.
Stefan
-----------------------
I second that!
Jim
Re: Compiling log4net with strong name and 3rd party dependencies
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-11, Curt Arnold wrote:
> On Aug 10, 2011, at 10:38 AM, Stefan Bodewig wrote:
>> I'd propose to not keep the signing key of future releases secret but
>> simply keep the full keypair inside the source tree.
>> Stefan
> I'm fine with that as long as it is a different key than that which
> signed the earlier releases which had some at least implied promise of
> signing key secrecy that we should not undo.
+1
That's why I proposed it for future releases.
> Likely that would mean that we would need to build assemblies with the
> previous key for those who want a dropin replacement for earlier
> log4net and figure out if we want to distribute compiled assembles
> with the open key or just distribute the source.
Right now I'd lean towards making breaking changes for a 1.3.x line of
releases and using the new key there, I'm not sure whether signing those
with the old key would be useful at all.
As for distributions, I think the community needs to rethink what type
of assemblies should be distributed anyway - I'm not convinced separate
Mono assemblies are needed anymore, for example. There may be value in
assemblies that are not strong named at all in addition to those signed
with an open key.
Stefan
Re: Compiling log4net with strong name and 3rd party dependencies
Posted by Curt Arnold <ca...@apache.org>.
On Aug 10, 2011, at 10:38 AM, Stefan Bodewig wrote:
> I'd propose to not keep the signing key of future releases secret but
> simply keep the full keypair inside the source tree.
>
> Stefan
I'm fine with that as long as it is a different key than that which signed the earlier releases which had some at least implied promise of signing key secrecy that we should not undo. Likely that would mean that we would need to build assemblies with the previous key for those who want a dropin replacement for earlier log4net and figure out if we want to distribute compiled assembles with the open key or just distribute the source.
Re: Compiling log4net with strong name and 3rd party dependencies
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-17, Piers Williams wrote:
> On 10 August 2011 23:38, Stefan Bodewig <bo...@apache.org> wrote:
>> This seems to be consensus by now by pretty much all Open Source
>> projects in the .NET space. Just hand out your signing key so people
>> can create their own patch builds - as they can do for any other
>> platform as well. There is absolutely zero security attached to that
>> key if used that way, but that doesn't matter since our releases are
>> signed using OpenPGP and we provide hashes of everything.
>> I'd propose to not keep the signing key of future releases secret but
>> simply keep the full keypair inside the source tree.
> I'm unconvinced that handing out the key like that is a good idea, though I
> quite understand why people have started to do it.
> Either way, in the case that a project *doesn't*, an app.config /
> machine.config binding redirect to your forked version (mapping the
> different different hash, version etc...) works just fine for keeping the
> 3rd party dependencies happy.
At the danger of embarrassing myself: it's been my understanding that
binding redirects can be used to redirect from one version of an
assembly with a given publicKeyToken to another but not from one token
to another.
What does a binding redirect look like if I want to redirect from
publicKeyToken"hash1" to publicKeyToken"hash2"?
Stefan
Re: Compiling log4net with strong name and 3rd party dependencies
Posted by Piers Williams <pi...@gmail.com>.
On 10 August 2011 23:38, Stefan Bodewig <bo...@apache.org> wrote:
>
> This seems to be consensus by now by pretty much all Open Source
> projects in the .NET space. Just hand out your signing key so people
> can create their own patch builds - as they can do for any other
> platform as well. There is absolutely zero security attached to that
> key if used that way, but that doesn't matter since our releases are
> signed using OpenPGP and we provide hashes of everything.
>
> I'd propose to not keep the signing key of future releases secret but
> simply keep the full keypair inside the source tree.
>
> Stefan
>
I'm unconvinced that handing out the key like that is a good idea, though I
quite understand why people have started to do it.
Either way, in the case that a project *doesn't*, an app.config /
machine.config binding redirect to your forked version (mapping the
different different hash, version etc...) works just fine for keeping the
3rd party dependencies happy.
--
piers
more pedantry at http://piers7.blogspot.com/