incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: status of PGP support in Maven
Date Mon, 22 Sep 2008 18:32:09 GMT
On 22/09/2008, Hiram Chirino <hiram@hiramchirino.com> wrote:
> On Mon, Sep 22, 2008 at 10:12 AM, sebb <sebbaz@gmail.com> wrote:
>  > On 22/09/2008, Hiram Chirino <hiram@hiramchirino.com> wrote:
>  >> The only reason I suggested including the sigs in the source distro is
>  >>  because a source build like Apache ServiceMix depends on hundreds of
>  >>  third party dependencies.. so an end user would need to end up
>  >>  trusting LOTs different signatures to get ServiceMix to build.
>  >>
>  >>  It would be easier if the end user could just trust the Apache source
>  >>  distro and also transitively trust the signatures that we trust for
>  >>  our dependencies.
>  >>
>  >
>
>
> I actually meant to say include the pub key for the dependency in the
>  source distro.
>
>
>  > So effectively you are proposing a secondary indirect signature for
>  > each of those artefacts.
>  >
>  > But instead of signing the checksum list, why not generate signatures
>  > for the artefacts themselves and check those?
>  >
>
>
> But I like that idea too for the cases where it's  a 3rd party
>  dependency which does not sign it's artifacts or we don't trust it's
>  signatures (perhaps we don't think they go far enough to secure their
>  keys).
>
>
>  > You could then store the Apache sigs in the Maven repo, and they would
>  > then be available to all Apache projects - and to any others who
>  > decided to trust the Apache key.
>  >
>  >>  The end user would still need to manually validate the source distro signature.
>  >>
>  >
>  > I can see that it would be an improvement over the existing Maven
>  > situation, but for me it does not go far enough.
>  >
>  > The problem is that the process of generating the checksum list does
>  > not scale well, and it forces every project to use fixed versions for
>  > each dependency.
>  >
>
>
> This should only be a problem while developing as official releases
>  should lock down the dependencies to known versions anyways.
>

As far as I know, many(most) releases depend on a minimum version, and
don't specify an upper version. How are you going to lock down
transitive dependencies, or are they not handled?

There's still the problem of scalability.

I think it might help your case if there was a fuller description of
the procedures that will need to be followed.

>
>  >>  Regards,
>  >>
>  >> Hiram
>  >>
>  >>
>  >>  On Sat, Sep 20, 2008 at 1:08 PM, Henning Schmiedehausen
>  >>  <henning@apache.org> wrote:
>  >>
>  >> > On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
>  >>  >> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
>  >>  >> <justin@erenkrantz.com> wrote:
>  >>  >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hiram@hiramchirino.com>
wrote:
>  >>  >> >> How about we include the signatures in the source distros?
 That way
>  >>  >> >> if you trust your source, then you can trust the dependencies
it
>  >>  >> >> downloads.
>  >>  >> >
>  >>  >> > Eww.  That'd be a giant gaping security hole.
>  >>  >>
>  >>  >> not necessarily, depends how it's done
>  >>  >>
>  >>  >> signing works through trusting the people who own the keys. given
>  >>  >> sufficient signaturees (to prevent small conspiracies), where the
>  >>  >> signatures are downloaded from shouldn't matter.
>  >>  >
>  >>  > Hiram suggested to put the signatures into the source, which in turn
is
>  >>  > also distributed from the repo. If you compromise the repo and change
>  >>  > the artifact, it is trivial to update the source artifact to contain
a
>  >>  > matching signature.
>  >>  >
>  >>  > This is a security hole. And I don't really care for some of the
>  >>  > proposed "high nineties" security solutions. Either a solution is secure
>  >>  > or it is not. Everything else is just FUD.
>  >>  >
>  >>  > The problem with the central repo is that you need an easy accessible
>  >>  > web of trust if you want validation. The Apache web of trust is
>  >>  > distributed and an overlay to the GPG web of trust. But if you live in
>  >>  > Juneau, Alaska, it is hard for you to access it and get a trust
>  >>  > relationship to it.
>  >>  >
>  >>  > There is a (bit rusty) proposal on how to improve this at
>  >>  > http://people.apache.org/~henkp/trust/
>  >>  >
>  >>  >        Ciao
>  >>  >                Henning
>  >>  >
>  >>  >
>  >>  >
>  >>  > ---------------------------------------------------------------------
>  >>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >>  >
>  >>  >
>  >>
>  >>
>  >>
>  >>
>  >> --
>  >>  Regards,
>  >>  Hiram
>  >>
>  >>  Blog: http://hiramchirino.com
>  >>
>  >>  Open Source SOA
>  >>  http://open.iona.com
>  >>
>  >>  ---------------------------------------------------------------------
>  >>
>  >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >
>  >
>
>
>
>  --
>  Regards,
>  Hiram
>
>  Blog: http://hiramchirino.com
>
>  Open Source SOA
>  http://open.iona.com
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message