As I understand it, the new signing key is publicly available. This means that there is no security advantage to signing log4net at all - anyone could alter the source, then rebuild and re-sign it. Since signing causes no end of issues with third-party libraries and NuGet, why sign log4net at all? If anyone must have it signed, they can always do so themselves.
Bill Sorensen -----Original Message----- From: Stefan Bodewig [mailto:[email protected]] Sent: Sunday, October 27, 2013 6:47 AM To: [email protected] Subject: Plans for 1.3.0 Hi all, we are currently thinking about calling the next release 1.3.0 and use this in order to introduce a few changes that are not (strictly) backwards compatible. One thing will be that we intend to drop support for all the 1.x frameworks - 2.x and above should remain at the level of support we currently have. The new/old-key distributions cause problems when you depend on two third party assemblies and either one uses a different strong name log4net. This can be resolved via GAC or probing path configurations but it isn't as easy as we'd want to. One solution we are currently pondering is giving the log4net assembly a new name - say log4net-13.dll - and sign it only using the new key and at the same time provide two "log4net.dll"s containing type forwards to the new assembly only. This sounds as if it could solve all reported problems but we may be overlooking something - we most probably do. Actually while I was writing this I wonder why we should keep old-key assemblies around at all when we rename the assembly, just a thought. Any comments on the plans - or ideas of APIs that feel clumsy and would be worth breaking in a "cleanish slate" release - are more than welcome. Nothing has been carved into stone, yet. Stefan
