Sometimes you need a signed binary. For example, anything that is itself signed needs all its dependencies to be signed.
On Mon, Oct 28, 2013 at 2:55 PM, Bill Sorensen <[email protected]> wrote: > 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 > >
