incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Date Thu, 18 Sep 2008 19:07:24 GMT
On 18/09/2008, Hiram Chirino <hiram@hiramchirino.com> wrote:
> On Thu, Sep 18, 2008 at 10:59 AM, sebb <sebbaz@gmail.com> wrote:
>  > On 18/09/2008, Hiram Chirino <hiram@hiramchirino.com> wrote:
>  >> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr.
>  >>
>  >> <wrowe@rowe-clan.net> 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: 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