incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: status of PGP support in Maven
Date Mon, 06 Oct 2008 14:08:19 GMT
On Fri, Oct 3, 2008 at 8:01 PM, Henning Schmiedehausen
<> wrote:
> On Fri, 2008-10-03 at 11:20 -0400, Noel J. Bergman wrote:
>> Henning Schmiedehausen wrote:
>> > There is a pretty nice proposal on
>> >, however this will again take a
>> > piece of "freedom of doing software at Apache" away and introduce some
>> > administrative overhead that all projects must implement and manage.
>> But, as you say, it is worth doing something, whether exactly that or not,
>> because
>> > Formalizing the signing of our releases would be a huge step towards a
>> > reliable validation for the Apache software releases.
>> > It still does not help you with third-party releases, though.
>> Is it our problem if you mean a third party, e.g., IBM, releasing our code
>> as part of their own commercial product?
> Actually I meant verifying/validating the third party dependencies that
> Apache projects *use*. So even if we go through all the pains of making
> sure that our users really get "apache-baz-1.0", it might just pull in
> "some-random-dependency-from-sourceforge-1.0" which can not be
> validated.
>        Ciao
>                Henning

There are maven plugins that can validate the checksums of 3rd party
dependencies.  Works well as long as:
A) You can trust that your apache-baz-1.0 source has not been tampered with.
B) The dependency had not been tampered with at the time that the
dependency was first added to the build.  (Since that's when the
expected checksum is calculated)

Problem A: is universal to all builds at apache even if it's a maven
based or make based build.  I guess this is what the GPG discussion is
Problem B: Could be further reduced if the 3rd party used some type
signing to help the apache developers validate that the 3rd party
artifact is indeed authentic.

If dependency checksum validation was encouraged by all our source
builds, I think Problem B would become even less of a problem because
you would get a network effect between all the source builds.  As more
more projects add a 3rd party dependency validated by a checksum, it
becomes harder to exploit that 3rd party dependency as the artifact
checksum gets checked by more and more builds.  Tampering with the
artifact would result some builds builds breaking and folks
investigating the tampering.  Therefore the most effective way to
tamper with a 3rd party artifact would be to do it when the 3rd party
artifact first gets deployed.  So in effect we reduce the
vulnerability window that exploits are effective in, which I think



Open Source SOA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message