> 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), what would be the correct behavior in terms of
providing verification?

> 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

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).

I don't have an answer.  Just questions about what we can do for Joe Random.

        --- Noel

Reply via email to