Hi Nicko, Please don't revert to the old days where log4net was not strong named. This would require all developers (including myself) to build log4net from source if they wanted to use it from an already strong named assembly.
At the moment, I can simply grab the log4net assembly, and use it 'as is'. I think my preferred solution would be for you to continue signing log4net with your private key (as you are currently doing). This means that developers who are using log4net 'out of the box' can use the distributed assembly without having to build it. It also means that customers are safe in the knowledge that if you replace their log4net assembly, they are getting a legitimate version. If developers need to make changes to log4net, then they will be forced to build it from source, and sign it with their own key pair. But their 'new' version could not be used to replace an existing log4net in other systems because of the different strong names. This protects customers from 'malicious' version of log4net. Also, if the developer is making changes to the code base, those changes should probably be fed back into the main product. If this happens, they can wait for the next release and have a log4net signed with your key pair if this is required. Regards Mark -----Original Message----- From: GlennDoten [mailto:[EMAIL PROTECTED] Sent: 21 June 2006 16:40 To: Log4NET Dev Subject: Re: Strong name private key policy 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 <[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 > > > -----Original Message----- > > From: Bob Hanson [mailto:[EMAIL PROTECTED] > > 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): [EMAIL PROTECTED] ICQ: 153149689 Yahoo Messenger: gdoten MSN Messenger: [EMAIL PROTECTED] IRC: ostinPowers Skype: [EMAIL PROTECTED] ___________________________________ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. Please notify the sender by e-mail or telephone. We utilise an anti-virus system and therefore any files sent via e-mail will have been checked for known viruses. You are however advised to run your own virus check before opening any attachments received as we will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received. Any views expressed by an individual within this e-mail do not necessarily reflect the views of Systems Union Group plc or any of its subsidiary companies.
