<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Eli Barzilay wrote at 04/09/2011 10:00 AM: <blockquote cite="mid:19872.26259.991300.158403@winooski.ccs.neu.edu" type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Oh, and I don't remember any concrete planet suggestions on this. </pre> </blockquote> 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. <a class="moz-txt-link-freetext" href="http://lists.racket-lang.org/users/archive/2003-March/002004.html">http://lists.racket-lang.org/users/archive/2003-March/002004.html</a> wrote: <blockquote type="cite">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.)</blockquote> 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.) <div class="moz-signature">-- <a class="moz-txt-link-freetext" href="http://www.neilvandyke.org/">http://www.neilvandyke.org/</a> </div> </body> </html>