Strong name private key policy

[Nicko Cadell <ni...@neoworks.com>]

All devs,

It was not my intention to change the strong name key for the 1.2.10
release. Due to some misadventure the key has changed between version
1.2.9 and 1.2.10. This has the undesirable effect of preventing binding
redirects between these version working.

I am still investigating where my key management procedures broke down.
But I think that it is now essential for log4net to examine our policy
towards strong naming, especially as this is supposed to be an open
source project. Does the private key form an integral part of the
'source'? It is not required to build an identically functional
assembly, but it is required to build an identical binary replacement
assembly.

Our current policy is to hold the strong name signing key privately.
This is the de facto policy carried over from pre Apache days, it has
not been official discussed in our time here apache. 

Essentially the strong name key forms part of the assembly identity. The
private key is not required to build functionally identical (or
derivate) versions of the log4net assembly. However it is required to
build assemblies with the same identity, i.e. that can be a binary drop
in replacement.

By releasing the strong name private key we will allow members of the
community to build their own versions of the log4net assembly
(regardless of functional changes) which can be used to replace the
log4net assembly shipped with other 3rd party applications. One of the
_features_ of the strong name identity (from the application's point of
view) is that it prevents an assembly being replaced without the
application knowing. If an application is using strong name binding to
load its assemblies then it is sure of the provenance of those
assemblies. If we release the private key then this is no longer the
case (with regard to the log4net assembly), any 3rd party can create an
assembly (which may or may not contain malicious code) that can be used
to substitute for the log4net assembly.

We need to decide if the strong name private key should remain private
or if we should release it under the terms of the Apache licence.

Regards,
Nicko 

> -----Original Message-----
> From: Bob Hanson [mailto:mnbob70@gmail.com] 
> Sent: 13 June 2006 17:13
> To: log4net-user@logging.apache.org
> Subject: new public key for 1.2.10?
> 
> According to discussion at 
> http://forum.springframework.net/showthread.php?t=470, the 
> public key has changed from version 1.2.9 to 1.2.10.
> 
> Was this by design? 
> 
> 

Re: Strong name private key policy

[GlennDoten <gd...@gmail.com>]

Nick, I think maybe your own choice is to "license" the private key.
Write something up that says "if you sign any log4net-owned assembly
using the official log4net private key and your code is malicious then
you are in trouble." Or something like that.

Here's the problem with an unsigned assembly. Whenever you use an
unsigned assembly in a project it means that if you were signing your
project's assembly then you can no longer do so; i.e., a signed
assembly *requires* that all assemblies it refers to are also signed.

I sign all my assemblies (even my test ones) because that seems to be
the easiest thing to do in the long term. Often, you will want to GAC
one or more assemblies and if they are all signed already you can
easily do that (you probably know the GAC requires assemblies to be
signed). You may also want to GAC the log4net assembly and if it isn't
signed you're out of luck.

Think also about code that is used by tools such as BizTalk. For some
strange reason, MS requires all assemblies with BizTalk orchestrations
to be signed and worse, GACed. If any of those use an unsigned version
of log4net.dll (which means the client DLL cannot be signed) then
BizTalk won't consume them. I'm sure there are other tools that
require this too.

So this is an interesting situation. Typically, you want to guard your
private key for the various reasons you mention. But then some sort of
private key is required for the reasons I give above.

One possible solution I see is that since log4net is typically
"locally" used (i.e., by a company's development group) you could
distribute everything but the key-pair that you use and people can add
their own key-pair to the project before building it. Of course, this
would mean that if you distributed pre-built assemblies they would
have a different key-pair so the versioning issues you mention would
arise.

Perhaps the best solution is to distribute log4net in source form only
and allow people to choose to add a key-pair to the solution or not.
Didn't an earlier version of log4net, like 2 years ago, work this way?

This is a tricky one; good luck with it!

-glenn-

On 6/21/06, Nicko Cadell <ni...@neoworks.com> wrote:
> All devs,
>
> It was not my intention to change the strong name key for the 1.2.10
> release. Due to some misadventure the key has changed between version
> 1.2.9 and 1.2.10. This has the undesirable effect of preventing binding
> redirects between these version working.
>
> I am still investigating where my key management procedures broke down.
> But I think that it is now essential for log4net to examine our policy
> towards strong naming, especially as this is supposed to be an open
> source project. Does the private key form an integral part of the
> 'source'? It is not required to build an identically functional
> assembly, but it is required to build an identical binary replacement
> assembly.
>
> Our current policy is to hold the strong name signing key privately.
> This is the de facto policy carried over from pre Apache days, it has
> not been official discussed in our time here apache.
>
> Essentially the strong name key forms part of the assembly identity. The
> private key is not required to build functionally identical (or
> derivate) versions of the log4net assembly. However it is required to
> build assemblies with the same identity, i.e. that can be a binary drop
> in replacement.
>
> By releasing the strong name private key we will allow members of the
> community to build their own versions of the log4net assembly
> (regardless of functional changes) which can be used to replace the
> log4net assembly shipped with other 3rd party applications. One of the
> _features_ of the strong name identity (from the application's point of
> view) is that it prevents an assembly being replaced without the
> application knowing. If an application is using strong name binding to
> load its assemblies then it is sure of the provenance of those
> assemblies. If we release the private key then this is no longer the
> case (with regard to the log4net assembly), any 3rd party can create an
> assembly (which may or may not contain malicious code) that can be used
> to substitute for the log4net assembly.
>
> We need to decide if the strong name private key should remain private
> or if we should release it under the terms of the Apache licence.
>
> Regards,
> Nicko
>
> > -----Original Message-----
> > From: Bob Hanson [mailto:mnbob70@gmail.com]
> > Sent: 13 June 2006 17:13
> > To: log4net-user@logging.apache.org
> > Subject: new public key for 1.2.10?
> >
> > According to discussion at
> > http://forum.springframework.net/showthread.php?t=470, the
> > public key has changed from version 1.2.9 to 1.2.10.
> >
> > Was this by design?
> >
> >
>


-- 
-glenn-
___________________________________
Google Talk (Jabber): gdoten@gmail.com
ICQ: 153149689
Yahoo Messenger: gdoten
MSN Messenger: gdoten@gmail.com
IRC: ostinPowers
Skype: gdoten@gmail.com
___________________________________

Re: Strong name private key policy

[Rjae Easton <rj...@gmail.com>]

I have been tempted to jump into this thread - ever since I saw signs
of "open-sourcing" log4net's private key. In all honesty I wanted to
see what the community would get to.

The recent dialog about code-signing - while useful - were really a
separate thread about .NET specifics e.g. assembly-loader, GAC
requirements, security demands. Glenn does this thread a great service
to get back to the only "decision point" here: whether to release the
private key.

I completely agree with Glenn on the single-owner approach. There is
simply no reason to expose your private key - otherwise it is fairly
useless in terms of security demands. The only addition I have to what
Glenn said is that when building - for code fix or improvement - you
can temporarily use the public key (delay-signing). Of course,
creating/using one's own generated key-pair will work too. I have used
delay-signed assemblies on several projects; "shared" assemblies are
still possible without the full private-key signing.

So I would vote to publish the public key and maintain tight control
over the private key.

On 6/22/06, GlennDoten <gd...@gmail.com> wrote:
> Nick, back to a solution to this quandary. I may have proposed this
> already but I'm not sure.
>
> Assumption: only the "official owner" of log4net should be able to
> sign the log4net.dll assembly with the "official" public/private key
> pair.
>
> Why this assumption? Otherwise, anyone could sign the assembly with
> the key pair and potential cause confusion, bad code, viruses,
> whatever. The assemblies distributed by the log4net team would be the
> only official ones that match a given published version of log4net. Of
> course, you'd want to publish the public key token on the log4net
> website so people can confirm they are using the officially blessed
> assemblies--think of this like how MD5 and SHA1 is used in other
> distributions. You should never distribute your private key, even
> under some sort of license, IMO.
>
> Now, as a local user of the log4net assembly I may uncover a bug or
> need to change the code. I have these options:
>
> 1. Report the bug and wait for a fix.
> 2. Fix the bug myself.
> 3. Request the new feature and wait for it to be rolled into the
> official distribution.
> 4. Add the feature myself (and like someone already mentioned, but a
> good open source citizen and send that code to the log4net team for
> consideration).
>
> In the case of (1) and (3) the "signed assembly problem" isn't.
> Eventually I'll get an assembly with the official key pair and off I
> go.
>
> In the case of (2) and (4) I'd have to create my own key pair to build
> my own (hopefully temporary) version of log4net.dll.
>
> Why wouldn't this work? It satisfies the needs I've read so far about
> a pre-built assembly being distributed with the official key pair. It
> satisfies the needs of those shops that can't wait for a bug fix
> and/or new feature. The official key pair would not change between
> versions, as it should not.
>
> Any feedback from the Apache overseers (or whatever they are called)?
>
> -glenn-
>
> On 6/21/06, Nicko Cadell <ni...@neoworks.com> wrote:
> > All devs,
> >
> > It was not my intention to change the strong name key for the 1.2.10
> > release. Due to some misadventure the key has changed between version
> > 1.2.9 and 1.2.10. This has the undesirable effect of preventing binding
> > redirects between these version working.
> >
> > I am still investigating where my key management procedures broke down.
> > But I think that it is now essential for log4net to examine our policy
> > towards strong naming, especially as this is supposed to be an open
> > source project. Does the private key form an integral part of the
> > 'source'? It is not required to build an identically functional
> > assembly, but it is required to build an identical binary replacement
> > assembly.
> >
> > Our current policy is to hold the strong name signing key privately.
> > This is the de facto policy carried over from pre Apache days, it has
> > not been official discussed in our time here apache.
> >
> > Essentially the strong name key forms part of the assembly identity. The
> > private key is not required to build functionally identical (or
> > derivate) versions of the log4net assembly. However it is required to
> > build assemblies with the same identity, i.e. that can be a binary drop
> > in replacement.
> >
> > By releasing the strong name private key we will allow members of the
> > community to build their own versions of the log4net assembly
> > (regardless of functional changes) which can be used to replace the
> > log4net assembly shipped with other 3rd party applications. One of the
> > _features_ of the strong name identity (from the application's point of
> > view) is that it prevents an assembly being replaced without the
> > application knowing. If an application is using strong name binding to
> > load its assemblies then it is sure of the provenance of those
> > assemblies. If we release the private key then this is no longer the
> > case (with regard to the log4net assembly), any 3rd party can create an
> > assembly (which may or may not contain malicious code) that can be used
> > to substitute for the log4net assembly.
> >
> > We need to decide if the strong name private key should remain private
> > or if we should release it under the terms of the Apache licence.
> >
> > Regards,
> > Nicko
>


-- 
Rjae Easton
blog: http://applanet.com/percs/
wiki: http://applanet.com/wiki/

Re: Strong name private key policy

[GlennDoten <gd...@gmail.com>]

Nick, back to a solution to this quandary. I may have proposed this
already but I'm not sure.

Assumption: only the "official owner" of log4net should be able to
sign the log4net.dll assembly with the "official" public/private key
pair.

Why this assumption? Otherwise, anyone could sign the assembly with
the key pair and potential cause confusion, bad code, viruses,
whatever. The assemblies distributed by the log4net team would be the
only official ones that match a given published version of log4net. Of
course, you'd want to publish the public key token on the log4net
website so people can confirm they are using the officially blessed
assemblies--think of this like how MD5 and SHA1 is used in other
distributions. You should never distribute your private key, even
under some sort of license, IMO.

Now, as a local user of the log4net assembly I may uncover a bug or
need to change the code. I have these options:

1. Report the bug and wait for a fix.
2. Fix the bug myself.
3. Request the new feature and wait for it to be rolled into the
official distribution.
4. Add the feature myself (and like someone already mentioned, but a
good open source citizen and send that code to the log4net team for
consideration).

In the case of (1) and (3) the "signed assembly problem" isn't.
Eventually I'll get an assembly with the official key pair and off I
go.

In the case of (2) and (4) I'd have to create my own key pair to build
my own (hopefully temporary) version of log4net.dll.

Why wouldn't this work? It satisfies the needs I've read so far about
a pre-built assembly being distributed with the official key pair. It
satisfies the needs of those shops that can't wait for a bug fix
and/or new feature. The official key pair would not change between
versions, as it should not.

Any feedback from the Apache overseers (or whatever they are called)?

-glenn-

On 6/21/06, Nicko Cadell <ni...@neoworks.com> wrote:
> All devs,
>
> It was not my intention to change the strong name key for the 1.2.10
> release. Due to some misadventure the key has changed between version
> 1.2.9 and 1.2.10. This has the undesirable effect of preventing binding
> redirects between these version working.
>
> I am still investigating where my key management procedures broke down.
> But I think that it is now essential for log4net to examine our policy
> towards strong naming, especially as this is supposed to be an open
> source project. Does the private key form an integral part of the
> 'source'? It is not required to build an identically functional
> assembly, but it is required to build an identical binary replacement
> assembly.
>
> Our current policy is to hold the strong name signing key privately.
> This is the de facto policy carried over from pre Apache days, it has
> not been official discussed in our time here apache.
>
> Essentially the strong name key forms part of the assembly identity. The
> private key is not required to build functionally identical (or
> derivate) versions of the log4net assembly. However it is required to
> build assemblies with the same identity, i.e. that can be a binary drop
> in replacement.
>
> By releasing the strong name private key we will allow members of the
> community to build their own versions of the log4net assembly
> (regardless of functional changes) which can be used to replace the
> log4net assembly shipped with other 3rd party applications. One of the
> _features_ of the strong name identity (from the application's point of
> view) is that it prevents an assembly being replaced without the
> application knowing. If an application is using strong name binding to
> load its assemblies then it is sure of the provenance of those
> assemblies. If we release the private key then this is no longer the
> case (with regard to the log4net assembly), any 3rd party can create an
> assembly (which may or may not contain malicious code) that can be used
> to substitute for the log4net assembly.
>
> We need to decide if the strong name private key should remain private
> or if we should release it under the terms of the Apache licence.
>
> Regards,
> Nicko