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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/
