On Thu, Sep 18, 2008 at 3:07 PM, sebb <[EMAIL PROTECTED]> wrote: > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> On Thu, Sep 18, 2008 at 10:59 AM, sebb <[EMAIL PROTECTED]> wrote: >> > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> >> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr. >> >> >> >> <[EMAIL PROTECTED]> wrote: >> >> >> >> > Similarly, the issue of signature validation is a significant flaw >> which >> >> > I also hope maven addresses even more promptly, and which they are >> aware >> >> > of. The alternatives are to take down maven until it is secure, or to >> >> > continue to populate maven with various released artifacts. And this >> too >> >> > isn't germane to the question above, which is; >> >> >> >> >> >> The signature validation issue has a simple fix which I have already >> >> mentioned earlier. I'm not sure why folks continue to think it's >> >> still a problem. All the projects need to do is enable a checksum >> >> validation plugin, and at least that problem is resolved. >> >> >> > >> > Not sure I agree that the checksum plugin solves the problem. >> > >> > As far as I can tell, all that the plugin does is to detect any >> > changes to dependencies that occur *after the checksum list is >> > initially generated* >> >> >> Agreed. >> >> >> > >> > Unless I'm mistaken, it does not guard against the orignal dependency >> > already being corrupt, nor does it protect the product itself. >> > >> >> >> So the responsibility is still on us, the upstream distributor, to >> verify the the checksums we list in our source distro are correct. > > And how do we do that? > We cannot use the Maven repo as it has already been compromised.
If you are a totally paranoid, you would build all the dependencies your self and use those checksums. :) Since that's not practical, you have to trust that an artifact on a maven repo has not been hacked.. or even validate it has not been hacked (perhaps the project provides a separate website with the checksums of the artifacts). But even if you get it wrong, it's not the end of the world.. The important thing is being able to detect and correct the problem. > >> 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. > > Only if our distro has not had its checksum list hacked. The checksums are part of the source distro. If the source distro you downloaded is hacked.. hey hack the checksum list.. the hacker might as well put the malicious code in the source code. > >> If a committer by mistake adds an invalid checksum for an artifact >> that he been hacked in his repo, hopefully, another developer doing >> the build will notice that the build fails due to checksum error if he >> has the valid artifact. At that point they can investigate who has >> the valid copy of the artifact. The more users that are building the >> software with the checksum validation, the better of chance you got at >> some one noticing a hacked repo artifact. > > Depends on when the hacked version was uploaded. > It's quite possible that every ASF use of the module will be after the > original hack. > Possible.. But I'm talking about a wider audience than the ASF. I hope if the ASF adopts this policy of using the checksum plugin, the maven folks adopt it as a standard practice. And then we have every other maven user out there helping detect repository attacks. >> If by chance all repos being used only have the hacked version of the >> artifact and, no one notices it hacked and we release with that.. then >> that would be a serious issue yes. I think we should handle that like > > Which is what we should protect against from the start. Sure.. but that starts at implementing good repository security. That is the start after all. > >> we would handle any serious security flaw in our products. Re-release >> with the flaw (checksum) corrected and advise all our users to >> upgrade. >> >> On a side note.. a GPG web of trust would help in trusting the >> original binary checksum. Note that down stream users of our source >> distro may not trust people we trust, so they may want those checksums >> anyways. > > How? By signing the checksum? > If so, fine, but then why not just sign the jar. > Yes I mean signing the artifacts. If you are adding a new dependency that has a trusted signature, it's a should be a no brainer to accept that the artifact has not been tampered with. But remember not all 3rd party artifacts are going to have trusted signers. Also, what happens if that key used to sign the artifact gets compromised.. so it might not be so trusted anymore.. So even GPG may not be the solve all of the problem of initial trust. >> >> > What's to stop the checksum list being corrupted? > > Any comment on this? To corrupt the checksum list.. the source disto must be hacked. At that point it's not a build tool issue. > >> > >> >> >> >> -- >> >> 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] > > -- 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]
