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. > 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. > 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. > 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. > 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. > > > What's to stop the checksum list being corrupted? Any comment on this? > > > >> > >> -- > >> 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]
