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: Summary
Date Thu, 02 Mar 2006 11:10:52 GMT
On 3/2/06, Niclas Hedhman <niclas@hedhman.org> wrote:
> On 3/2/06, Brett Porter <brett.porter@gmail.com> wrote:
> > I understand, but that requires that you get and importa keys, which
> > is a much more sophisticated operation. All we are using the sha1 for
> > is to check that the download didn't get cut off halfway through.
> >
>  I think Brett has a point. Keep the md5 and/or sha1 for simple download
> verification, at least for quite a while. Meanwhile, Maven folks and we who
> do those automated download tools, can start look into a pgp driven solution
> which solves both the download integrity concern as well as the security
> aspects. But I think that will take a year or two, before it has been pushed
> out and can replace the checksum...

md5 and sh1 are nice and easy to verify in java; no extra libs. pgp
needs bouncy castle.

In smartfrog, you can declare a deployment descriptor not just the
version of a lib to d/l, but its md5/sha1 checksum, which is then used
to check the integrity of the app: the deployment will fail if the
checksum is unequal.

the deploymend descriptor itself then goes into a signed jar, which
the daemon retrieves the descriptor from, verifying the signing in the
process. And the daemons only trust JAR files signed by the select few
entitities you explicitly add: there is no default. As a result, the
sha1 checksums of the redistributed artifacts are the end of the
security chain, which is about as strong as Sun's JAR signing
mechanism (which is MD5, right?)

Interestingly we dont redist Smartfrog signed, even though we could,
because then the sun classloader switches into wierd-mode, every jar
signed is inherently sealed except to other jars signed by the same
signatories, even if you dont say "sealed" in the manifest. this has
adverse consequences. For example, hibernate doesnt work properly when
trying to persist classes in signed JARs, because it tries to create
new proxy classes in the same package.

I dont understand all this security stuff; I have a colleague who
claims to, and he is sufficiently paranoid that I have to go with him.
He doesnt trust TPMs because the government may have got there first,
even though they were invented in our building, by people we know.


View raw message