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, 25 Sep 2006 20:17:49 GMT
On Mon, 2006-09-25 at 11:05 +1000, Brett Porter wrote:
> On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:


> > given that the repository is secure then a checksum should be good
> > enough and is easier for users to understand.
> I'd certainly like to start there with the options in the document.  
> So, cleaning up the checksums in the repository, making sure Maven  
> can pull them from the source repository rather than a mirror, and  
> allowing them to be hardcoded into the POM would all make for a  
> reasonable security system.

in terms of a replacement attack where someone subverts a mirror, i
would say so. 

AIUI both MD5 and SHA1 have been broken in a technical sense but should
be ok from a practical perspective for the next few years. i don't think
that we need to worry overly about this
since we use detached signatures, if these hashing algorithms are
considered too weak for our purposes, we would need to be very careful
about the signing algorithms we allow and choose only algorithms which
do not rely on these hash algorithms. we would also need to ensure that
the key lengths were chosen carefully.

digital signatures definitely provide a lot of extra security at a low
cost but do require  knowledge to interpret. 

> However, I got the indication that some people wouldn't think this  
> was sufficient.

i don't think that checking checksums alone is sufficient but it is a

checking checksums should be good enough for most users provided that
the trustworthiness of the checksums can be guaranteed. it's this last
bit which is difficult. i don't see any easy solution to this.

> > it's really about the trust model.
> >
> > one issue is that determined attackers could easily this system if
> > second or third had signatures are trusted transitively. mallory
> > legitimately gets a connection to the web of trust then fakes an  
> > entire
> > sub-graph populated by fictional characters. this would be very
> > convincing to an automated system with only moderate risk to  
> > mallory who
> > could claim ignorance of the scam when confronted.
> Right. I think this is best counteracted by checking both the trust  
> in the person's key, and a secondary method of associating them with  
> the project that you are checking. That's starting to make the system  
> a bit complicated though.

if you know that the key is used to sign releases for that project then
the identity of the signer is not relevant. 

> > multiple signatures for each release may be a good way to cheaply
> > increase security. the release managers could sign, the maven uploader
> > could also sign to indicate that they had verified the release  
> > managers
> > signature. a maven auto-signer could add another signature to indicate
> > that it had been uploaded through the official mechanism. a scoring
> > system could be used to present this information to the user.
> This is interesting, but I worry that the complexity makes it harder  
> for the user to really answer the question of whether they trust it.  

a scoring system is just a simple way to present the result in a form
which does not require a lot of knowledge. for example:

*          trusted autosign 
***       trusted autosign plus trusted uploader signature or trusted
release manager
*****     trusted autosign plus trusted uploader signature plus trusted
release manager signature

i think that most users would understand 5 star security rating better
than the explanation the right. it's also less to read. maybe expert
users could customise the scoring system.

> I think it needs to be a simple question for them to answer themselves.

maybe we're asking the wrong question...

vanishingly few users are in a position to form any simple rational
judgement about which keys to trust. they just don't have the knowledge
and even if they did there are just too many open source release

rather than users being asked whether they trust a particular key,
perhaps it would be better use a system of signed imports. a user may
decide to trust a list matching keys to groups based on a good maven
master signature. this puts the control in the hands of the user but
ensures that they should have the knowledge necessary to make a rational
judgement. efficient, too. 

could use this system to allow users to blacklist keys too.

- robert

View raw message