Re: Strong names in Open Source

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Justin Rogers (Justin_at_games4dotnet.com)
Date: 03/15/04 

Date: Sun, 14 Mar 2004 18:35:41 -0800

Yes, I highly recommend automatically generating a key rather than including
one in the tree. Adding an sn -k buildKey.snk is much more secure in the long
run, since every dev will get their own special key and there won't be any
full trust issues later down the road. 

-- 
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers
"Jens Thiel" <MSDN@Thiel.de> wrote in message
news:O7jC2giCEHA.240@tk2msftngp13.phx.gbl...
> "Pete Davis" <pdavis68@hotmail.com> wrote
> > I suppose what
> > I'll do is stick a dummy key in with the source so it's compilable but
> keep
> > the real key hidden and use it for releases.
>
> Hi Pete, I wouldn't do that, as people will start to actually use the dummy
> key and eventually grant full trust - doors wide open, I would say...
>
> You should either include your public key, enable delay signing and add a
> README that describes how to disable verification - OR - include no key at
> all and add a keygen batch file or a makefile so that everyone has their own
> keys to play with (I now favour this approach as disabling verification can
> lead to the same security holes described above...).
>
> Keep the private key to sign official releases made by you, so that people
> can actually trust that key - or their very own. If you ever hand the
> project to someone else or a group of maintainers establish a release policy
> and use the private key accordingly.
>
> Keeping the private key doesn't violate OS. Everybody can still release
> their own versions, but nobody can use your name/key to claim that their
> changes are trustworthy or have been approved by you.
>
> Jens.
>
> -- 
> http://ManagedXLL.net/  |  http://jens-thiel.de/  |  http://QuantLib.net/
> Replace MSDN with my first name when replying to my email address!
>
>

Relevant Pages

  • Re: Strong names in Open Source
    ... "Pete Davis" wrote ... > I'll do is stick a dummy key in with the source so it's compilable but ... README that describes how to disable verification - OR - include no key at ... Keep the private key to sign official releases made by you, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Strong names in Open Source
    ... "Pete Davis" wrote ... > I'll do is stick a dummy key in with the source so it's compilable but ... README that describes how to disable verification - OR - include no key at ... Keep the private key to sign official releases made by you, ...
    (microsoft.public.dotnet.framework)
  • Re: Strong names in Open Source
    ... >> I'll do is stick a dummy key in with the source so it's compilable but> keep ... > Hi Pete, I wouldn't do that, as people will start to actually use the dummy> key and eventually grant full trust - doors wide open, I would say... ... > You should either include your public key, enable delay signing and add a> README that describes how to disable verification - OR - include no key at> all and add a keygen batch file or a makefile so that everyone has their own ... If you ever hand the> project to someone else or a group of maintainers establish a release policy> and use the private key accordingly. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: CA Q
    ... I'm gonna start a new Root CA company. ... that I've done so far is issue a certificate to my IIS webserver. ... that possesses that the private key is reasonably the party that was issued the key and that the keys can used used for the attempted operation. ... This is where certification authorities come into play - they provide the trust structure. ...
    (microsoft.public.cert.exam.mcse)
  • Re: Fighting stupidity
    ... the second procedure may be better: ... generation software on A. If you don't trust A to do a good job of that, ... It's a good rule of thumb that the ... owner should generate the private key, ...
    (sci.crypt)