On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 10:12 AM, sebb <[EMAIL PROTECTED]> wrote: > > On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> 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 > >> <[EMAIL PROTECTED]> 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 > >> >> <[EMAIL PROTECTED]> wrote: > >> >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > >> > >> > >> -- > >> Regards, > >> Hiram > >> > >> Blog: http://hiramchirino.com > >> > >> Open Source SOA > >> http://open.iona.com > >> > >> --------------------------------------------------------------------- > >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > Open Source SOA > http://open.iona.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
