www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <steve.lough...@gmail.com>
Subject Re: maven2 based releases for the james project and ASF policy
Date Mon, 25 Sep 2006 21:56:03 GMT
On 25/09/06, robert burrell donkin <rdonkin@apache.org> wrote:
> On Mon, 2006-09-25 at 11:05 +1000, Brett Porter wrote:
> > On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:
> <snip>
> > > 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

Md5 is what RPM distro's are based from; if its owned then linux is too.

Even so, a design you start today has to think more about the
future.The big risk is that someone deliberately creates a collision
and releases the good file to the repository, while retaining the bad
file for subversion on a mirror. I dont know if zip files are easily
subverted this way.

Sha1+MD5 together is good.

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

The biggest problem with starting to add security is the need to do
end-to-end security. right up from the moment somebody downloads it.
SSH is the best example of paranoia at work, such as the way it wont
read .ssh if the directory is world readable.

I could imagine a privilege escalation if one user kept their keys in
a directory that was group writeable, and of course there's no way to
check for this in Java (exec a shell script?). You'd add an extra
trusted key then serve up subverted artifacts under the new key. You
would have to hit the proxy settings too, perhaps, or a local mirror

Realistically, I dont worry about this because most projects I've been
on use a private SCM-managed repository. Anyone running binaries from
a shared file system have implicit trust in the rest of the group. But
once you try and do security, you do have to worry about all of these
things, and be more rigorous than before


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