Old / new key flaw

2011-12-23 Thread Ramon Smits
What is it with this old/new key?

http://logging.apache.org/log4net/download_log4net.cgi


I can share some thought about this new key philosophy regarding they
anyone should be able to patch it but I think it is wrong. How can I
validate a package from untrusted sources if they have access to the
'official' private key ?

If anyone needs strong named assemblies then that is for reasons. If they
want to have a patchable log4net then they should compile their own version
with their own key.


For example, somebody has created a log4net nuget :
http://nuget.org/packages/log4net

How can I validate if this is an official binary? It could do al sorts of
stuff if everybody can just recompile it and put it on such a big site as
nuget.org


This is just bad and my guess is that if the official release is not the
old key that you just killed log4net as nobody wants to recompile all their
dependancies.

And still, if you want to move to a new 'public' key pair (which as I
mentioned is a bad bad bad thing) then dont create an official 'old' key
binary.

-- 
Ramon


RE: Old / new key flaw

2011-12-23 Thread Walden H. Leverich
Ramon,

You can validate the officialness of a binary the same way every other 
non-.net system does it, via the MD5 or pgp signature of the official release. 
IIRC, there were two reasons behind still needing the signed release, first, 
some companies _require_ that the software be signed, doesn't matter by whom, 
but it must be signed. And the second reason was that you can't put it in the 
GAC if it's not signed so it you want a copy in the GAC then you have to be 
able to sign it. By keeping both the old and new keys active you can stay with 
the totally-official signed copy if you want, and you can get a little more 
flexibility if you want. Choice is yours.

-Walden


--
Walden H Leverich III
Tech Software 
BEC - IRBManager
(516) 627-3800 x3051
wald...@techsoftinc.commailto:wald...@techsoftinc.com
http://www.TechSoftInc.comhttp://www.techsoftinc.com/
http://www.IRBManager.comhttp://www.irbmanager.com/

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)

From: Ramon Smits [mailto:ramon.sm...@gmail.com]
Sent: Friday, December 23, 2011 3:49 AM
To: log4net-dev@logging.apache.org
Subject: Old / new key flaw


What is it with this old/new key?

http://logging.apache.org/log4net/download_log4net.cgi


I can share some thought about this new key philosophy regarding they anyone 
should be able to patch it but I think it is wrong. How can I validate a 
package from untrusted sources if they have access to the 'official' private 
key ?

If anyone needs strong named assemblies then that is for reasons. If they want 
to have a patchable log4net then they should compile their own version with 
their own key.


For example, somebody has created a log4net nuget : 
http://nuget.org/packages/log4net

How can I validate if this is an official binary? It could do al sorts of stuff 
if everybody can just recompile it and put it on such a big site as 
nuget.orghttp://nuget.org


This is just bad and my guess is that if the official release is not the old 
key that you just killed log4net as nobody wants to recompile all their 
dependancies.

And still, if you want to move to a new 'public' key pair (which as I mentioned 
is a bad bad bad thing) then dont create an official 'old' key binary.

--
Ramon



Re: Old / new key flaw

2011-12-23 Thread Stefan Bodewig
On 2011-12-23, Ramon Smits wrote:

 I can share some thought about this new key philosophy regarding they
 anyone should be able to patch it but I think it is wrong. How can I
 validate a package from untrusted sources if they have access to the
 'official' private key ?

The only official binary release is the one you download from an Apache
mirror and you can validate the PGP signature.

 For example, somebody has created a log4net nuget :
 http://nuget.org/packages/log4net

 How can I validate if this is an official binary?

It is not as the log4net community doesn't have any control over it.

Stefan