On Thu, Sep 18, 2008 at 4:57 PM, sebb <[EMAIL PROTECTED]> wrote: > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> On Thu, Sep 18, 2008 at 2:26 PM, William A. Rowe, Jr. >> >> <[EMAIL PROTECTED]> wrote: >> >> > Hiram Chirino wrote: >> >> >> >> So the responsibility is still on us, the upstream distributor, to >> >> verify the the checksums we list in our source distro are correct. >> >> But at least by doing this, down stream users of our source distros >> >> can rest assured that the dependencies that they are using are the >> >> correct ones. >> > >> > Not if there is a man in the middle attack. If you didn't notice the >> > recent noise w.r.t. DNS pollution, that's the very point of that vector. >> > Had it been exploited, tens of thousands of download users could have >> > been presented with inauthentic maven artifacts, complete with their >> > freshly corresponding checksums. Welcome to the internet. >> >> >> Yes, but that kind of attack would only affect me if It's the first >> time I'm creating a dependency to that artifact. > > Which will be the case for everyone intially. > > Suppose you want to create a checksum list for Apache Foo. > This uses say 30 Maven artefacts. > You check each one against the official release version to validate > the checksum list. > > Someone else creates list for Apache Wee. > They have to go through the same process of validation. > > Someone else creates another list for Apache Foo. > They have to go through the same process of validation. > > There's no easy way to share the result of a validation, except > perhaps with a TLP. > > Whereas once a Maven artefact is signed, everyone who trusts the > signature knows it is OK. Seems to me a lot less work overall. >
You still have the problem of how do users start trusting the signature? What if the signature is also hacked. This is a recursive discussion IMHO. >> Further more, other >> existing users of the artifact would detect the artifact replacement, >> and act to get the problem corrected. > > If you don't notice the problem, why would they notice? Not all users start using a dependency at the same time. Odds are low that a dependency gets hacked a soon as it gets deployed. Common and that means old artifacts would be the most likely targets for malicious attacks. And if it's an old artifact, chances are the lots of folks know the right checksum for it. > >> I consider the checksum >> solution very similar to how SSH work in asking you to verify your >> initial connection to a host. It's not 100% secure, but in practical >> use, it's in the high 90s. :) >> > > Or the low 10s - who knows? > Guess you don't trust SSH either eh? :) >> > > How does the process cope with a dependency on commons-foo, version > 1.2 or later? > Maven releases should pin down to a specific revision for this to work. > AIUI, Maven can pick a later version of a dependency, which may not > have been available when the checksum list was created. > > The advantage of signatures is that if you trust the signer, you can > trust the signed artefact. > That's not true for checksums, which require additional validation. > Signatures a handy and I think they will make trusting checksums easier.. But the problem is that not all our dependencies have signed artifacts that we can trust so we need to work with checksums. >> -- >> >> 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]
