www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: maven2 based releases for the james project and ASF policy
Date Mon, 25 Sep 2006 01:05:43 GMT

On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:

> perhaps (but then why not use standard jar signing...?)

I pointed that out in the proposal - that can be used when suitable,  
but the repository generally needs to be independent of Java solutions.

> i think that the substantial question is whether a hierarchical trust
> model is more suitable for release verification than a distributed  
> one.


> one of the problems is that a web-of-trust cannot be used without
> knowledge. a user must understand the difference between a good
> signature by an untrusted key and a bad signature by a trusted key. i
> think that (with effort) this could be explained in a few hundred  
> words
> but the user would need to read it.

This is true. It may be wise to make this available, but not the  
default. We need to balance out the advantage of basic security  
instead of no security, vs. giving a false sense of security by  
making it too transparent.

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

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

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

> 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.  
I think it needs to be a simple question for them to answer themselves.

[snip rest I generally agree with]

- Brett

View raw message