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:

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.




"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

Reply via email to