|
From: Levi K. <LKh...@th...> - 2004-11-17 20:37:45
|
Mike Roberts <mik...@gm...> wrote on 11/17/2004 02:39:59 PM: > Published builds should use a consistent key. I wonder why, is there another reason besides making binding redirection possible what's the problem with using one-time keys for releases? (just curious) > On Wed, 17 Nov 2004 14:26:44 +0530, Owen Rogers > <or...@th...> wrote: > > > > opening the private key makes assembly spoofing very simple > > true. but how concerned are we with spoofing? this is an open source > > project after all. the key is just a part of the source. > > Urrr, no. (Or it shouldn't be). Private keys should be stored *only* > on the build server in a (relatively) secure way. Developer builds > (i.e. non build-server builds) should use no key, or a 'use once' key. Why not use delay signing, where the public key is widely available and can be used for partial signing. Developers register partially signed assemblies for 'skip verification' using sn.exe and thus can use them. Then when it's time to release someone who keeps the private key (and has the final authority over releases) uses it to complete the signing process. > In fact its perfectly reasonable to expect your buildserver to have > one key as a machine-wide resource. This is a service we could setup > on CCNetLive, and could pass through the key location to the build > script as a CruiseControl.NET property. With delay signing scheme only the person publishing releases would need (and have access to) the private key. Regards, - Levi |