It seems we have several divergent requirements for signing; we need a
non-signed version for non GAC installations, a version signed with a
publicly available community key to allow separate components to use the
same instance, and possibly a version signed with a non-public key
coinciding with a release to match Microsoft's vision of an author signed
assembly.
The later build could be provided by a trusted third party, as it would
not be a truly 'open' version as no-one else could update the resultant
library. Obviously anyone who actually wants a trusted version of log4net
(or any other open source project for that matter) should inspect and
compile the source themselves, but having a build that is a definite
known release might help in some situations.
I'd suggest we release a community key that anyone producing a signed
version of log4net can use, to allow interoperability between versions
shipped with different libraries and products and produce a release build
signed with a separate key whenever we get to a suitable milestone.
Niall
On Wed, 21 Jun 2006, Whitner, Tom wrote:
> We are facing a similar question with some internal code. We have
> decided, at least for now, to produce both strong named and non-strong
> named binaries. Most agree that the strong named option is preferred.
> However, due to ASP.NET'sbehavior when loading strong named assemblies
> (i.e. it requires the GAC), not all individuals can/will tolerate GAC
> installation on highly locked down server. Hence, having the non-strong
> versions has become a necessity.
>
> - Tom
>
> -----Original Message-----
> From: Nicko Cadell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 21, 2006 1:59 PM
> To: Log4NET Dev
> Subject: RE: Strong name private key policy
>
>
>
> > 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.
>
> I don't think that releasing versions of log4net that are not strongly
> named is an option we can take.
>
> The only question is do we open source the strong name private key or do
> we keep it private (as we currently do).
>
> If we do not make our strong name private key open then users of
> applications that bind to the log4net strong name cannot build and
> substitute their own version of the log4net assembly. The only way in
> which they could would be it the main application is open source and
> therefore they can rebuild it from source, and therefore change its
> binding to a different log4net strong name.
>
> There needs to be a balance between application author security and user
> freedoms. At the moment we come down on the side of the application
> author and do curtail the user's freedom to replace the log4net binary.
> I believe that this is Microsoft's intention in designing the strong
> name binding system, especially as they do not allow a binding redirect
> configuration on the user's machine to redirect from one public key to
> another (only version may be redirected).
>
> It is likely that we will need to discuss this situation with the wider
> Apache community rather than just the log4net or the other Apache .net
> projects.
>
> Nicko
>
>
>
--
Niall Daley
Log4net Dev
