www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
Subject Re: maven2 based releases for the james project and ASF policy
Date Mon, 18 Sep 2006 22:04:31 GMT
On Mon, 2006-09-18 at 08:30 +1000, Brett Porter wrote: 
> On 17/09/06, Stefano Bagnara <apache@bago.org> wrote:
> > One of James PMC members is concerned (and we, other PMC member, agree
> > on his concerns) about the security issues introduced by downloading
> > artifacts from ibiblio or its mirrors, so we are trying to find an
> > interim solution while ASF define a common way.
> 
> BTW, as I'm sure Noel is listening - I'm still waiting on his feedback
> to the proposal I put up specifically about his concerns.
> 
> http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements

i've listed a some comments below about the details below but i'm a
little worried about whether the trust model is well enough thought
through. i think issues of key acquisition and trust have become a
little tangled up together.

but i'm very glad that someone's finally been willing to stick their
head about the parapet and create a concrete proposal

(from document)

> The Maven installation will contain a private key used to sign Maven
> PMC members release keys. 

typo? should this be public key?

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? 

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.

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. 

or maybe i'm missing something important...

> It may also be used to sign other ASF releases, and sync providers
> keys. 

the more signatures the better

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.

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

> 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

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


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

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. 

- robert

Mime
View raw message