www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Porter" <brett.por...@gmail.com>
Subject Re: maven2 based releases for the james project and ASF policy
Date Fri, 22 Sep 2006 06:06:08 GMT
On 19/09/06, robert burrell donkin <rdonkin@apache.org> wrote:
> > The Maven installation will contain a private key used to sign Maven
> > PMC members release keys.
>
> typo? should this be public key?

Yes, thanks.

> i don't understand why a single key should be shipped. seems a bit
> hierarchical, bit more like a certificate. what happens if that key has
> to be revoked?

I'm afraid I'm going to need someone with more expertise on the topic
to shed some light on this aspect. Perhaps a certificate is more
suitable.

>
> the user is going to be asked to trust the integrity of the maven
> release and the default selection of keys whether it's one or many.

Yes, but I think that's required anyway. Anyone who'd convince you to
download something that is an altered release could simply take out
the key checks (or leave it there and add their own key as you say so
it looks the same but silently allows malicious code). I;m not sure
there's a way we can get around that other to ensure the initial down
is signed and strongly encourage checking it on the download page.

> when using a web-of-trust model the obvious keys to ship are those which
> are most connected. taking a look at the ASF web-of-trust
> (http://people.apache.org/~henkp/trust/apache.html) shipped a dozen or
> keys well used keys would give good coverage.

That could be a better alternative if having a Maven key to sign them
doesn't make practical sense.

> note that if this maven key has a special role in the proposed then it
> would need to be kept very secret. this means that signing subkeys with
> limited durations would have to be used to sign the majority of
> artifacts. some libraries have issues with signing subkeys.

Yeah, this is probably one big argument against it. If instead of a
Maven key we have individual keys signing each other than we don't
have to worry about the secure location of the maven private key.

>
> > Should a user not wish to accept this initial set of keys, they can
> > simply remove the installation key ring and manually install keys they
> > wish to trust.
>
> i'm confused. AIUI the keys in a keyring are by default not trusted.
> having keys in the keyring means that they do not need to be fetched
> from a server or obtained manually. assigning trusting is an extra
> step.
>
> if maven wants to set up an openpgp compatible keyring with trusted
> defaults then a private key would need to be generated for each keyring
> during installation. to do this properly means an interactive session.
> the user could be prompted to trust or not trust a sequence of
> recommendations during this session.

I probably hadn't thought the implementation of thatt area through
enough - I was anticipating that the Maven default key(s) would be
trusted already and the user would intervene in adding extras.

Will give this section more thought.

>
> > Note that in both of the above cases, they key should be downloaded
> > from a trusted keyserver
>
> no public keyserver can be trusted to trusted keys: they make no promise
> about identity

I'm not even sure what I meant there now. Will look again :)

>
> > or KEYS file (as specified in settings.xml - see below), not from the
> > repository that the artifact is being downloaded from.
>
> i'm a little confused about this. it doesn't matter where the key is
> obtained from: what question is identity. the question is which keys to
> trust for what purposes.

Right, but surely a KEYS file on the actual web server is the closest
we'll get to a trusted source if you haven't met someone in person?

> > By default, all keys in the user's keyring will be accepted. However,
> > to strengthen a requirement, a project may require that the key be a
> > particular one, or signed by a particular key. The key provided might
> > be either an email address or the key ID.
>
> email address is absolutely worthless. keyID is not secure. the
> fingerprint should be used.

This was really to restrict the keys trusted for a certain dependency
(I trust open symphony for webwork, but I don't for commons-logging).
So the fingerprint would definitely be used in establishing the trust
of the publci key you already have.

> if a project requires that a particular key is used then the
> web-of-trust should be ignored and that key downloaded from a public
> server and the signature checked by that key. in this case, it's
> probably not safe to consider keys trusted by this key as trusted. the
> web-of-trust model vouches for identity not authorization.

Right.

Thanks for all the feedback! I'll try and clarify the document based
on it, but it's certainly given me more to think about.

Cheers,
Brett

Mime
View raw message