[racket] require url?

Eli Barzilay wrote at 04/09/2011 10:00 AM:
>>> Isn't this just old-fashioned code signing.  I think people talked about  it for PLaneT multiple times in the past, before Chrome existed.  Or am  I misunderstanding?
>>>       
>> I don't know wearher it's old-fashioned or not, butthe thing thatI've never seen before is using a single key per package and trusting itfor further updates -- which is very different from the usual key per person that requires trusting the channel you're getting it through.
>>     
>
> Oh, and I don't remember any concrete planet suggestions on this.
>   

It's harder to find PLaneT package signing in the list archives than I 
thought it would be, but below is one mention I found from 8 years ago.

http://lists.racket-lang.org/users/archive/2003-March/002004.html wrote:

> The biggest risk may be when author A's package is well-established 
> and widely used, so bad guy B uploads a trojaned update.  Very simple 
> GnuPG signing of packages by the authors would be a good way to reduce 
> this threat.  The CSPAN user update program could automatically verify 
> the signature, and the author program could offer to sign the package 
> before uploading to CSPAN.  There need not even be a centralized key 
> ring -- simply knowing that the same key that signed your current 
> version signed the new version would make things harder for a badguy.  
> Signing doesn't need to be in the first release of CSPAN tools, but I 
> think they should be designed to easily accomodate author-signing 
> later.  (I'm intentionally avoiding the idea of bureaucratic signing 
> by separate reviewers, etc.)

This also includes the same idea of "using a single key per package and 
trusting it for further updates".  I think it's an obvious way of using 
signing, and I'm sure the same idea has been thought of by others many 
times before that.


By the way, a key per account is somewhat better than key per package, 
because, in the worst case of per-account, it's at least as good as key 
per-package, but in better cases, there is more reputation associated 
with per-account, and per-account trust can jumpstart trust of a new 
package.  (In practice, your `per-account' design would probably permit 
multiple keys per person/account, and there be a many-to-one association 
of key-to-package.  That permits things like key revocation without 
discarding the account, and an organization using a single account for 
branding to have multiple keys that it prefers compartmentalize on a 
per-package basis, like if one package needed to be signed in a 
less-secure environment than usual.)

-- 
http://www.neilvandyke.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110409/90c77fe8/attachment.html>