logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Dearing <zippy1...@gmail.com>
Subject Re: Plans for 1.3.0
Date Mon, 28 Oct 2013 18:59:23 GMT
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 <bsorensen@idtdna.com> 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:bodewig@apache.org]
> Sent: Sunday, October 27, 2013 6:47 AM
> To: log4net-user@logging.apache.org
> 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
>
>

Mime
View raw message