Noel J. Bergman wrote: >>Having the keys connected to each other is not useful. What is useful is >>having them connected to someone you trust. > > >>> Suppose there is a downloader who wants to verify a /httpd/ package. >>> Unless he/she allready trusts some key in the set, he/she has no >>> clue how to /use/ the trust is the httpd key set. > > >>That's what Keyman is for :-) > > > Is this something that should be considered with respect to the Repository > effort? We already have the idea that since the repository will be > mirrored, we have to include verification. > > The repository needs to be neutral in terms of supporting distribution of > something like platform-specific code httpd as well as Java projects. CPAN, > JNLP, dependency location and loading, RPM installing, etc., are concepts > layered on top of a basic repository construct. But right above the basic > storage is verification, and if we had a specification and tools (a Java > version for portability)
Haha, very funny. > what would be the correct behavior in terms of > providing verification? Keyman is documented here: http://keyman.aldigital.co.uk/ There's also an implementation in Perl for, err, portability. >>What I said: "how hard is it for Joe Random to find a path from his key >>to the code signing key?" - though really I mean "from a key he trusts >>to the code signing key". > > > Here is where I see a problem. Not with process, but with people. > > Joe Random downloads software, doesn't understand signing, and just wants > someone to say that everything will be OK. The average linux user may be > more clueful than the average Windows user (over 90% of which are largely > computer illiterate), but that's changing as linux becomes more consumer > friendly, and Mac OS X users are no more competent than their Windows > counterparts. Perhaps this is why some people feel that MD5 is as good as > PGP. > > As for finding a key that Joe Random trusts, whom would you suggest that Joe > trust? Joe trusts whomever he's told to trust. Joe trusts the Root CAs > that are installed in Joe's browser and mail program. But Joe almost > certainly doesn't know any particular person to trust, and almost certainly > has no personal connection to a Web of Trust. Yet, Joe is the person > downloading and using the software. > > And although we know that "trust" only means that we have reason to trust > the IDENTITY of the signer, that's not what Joe Random will take from the > term. Joe will take it to mean that the code is trustworthy, not the > identity of the code signer. > > So what can we do for Joe Random? It seems to me that what Joe wants is to > know that he has downloaded software that hasn't been corrupted. I doubt > that he has any interest in the person who did the package, but rather the > entity whose name is associated with the package (the ASF). The Keyman documentation discusses these issues. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
