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
