Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 72.14.220.158 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=CI2VSOETOGrAw5Z5FziDikk3/V1yjUx4H9GtsqenTDEr+6aGjriu0EY53f+wMPoQY1
         vA9uJGFU8vDPyFL/9MrHtUNr1cZj5hGs7m3hqUdJ63W1gdLg13MWuH54DDgnHO//FQmL
         QwaR+dsiEYKcQXN9ZfuErS7TXFfVx0IJooQaA=
Message-ID: <25aac9fc0809181207o417967eft7a5ee1127fb90956@mail.gmail.com>
Date: Thu, 18 Sep 2008 20:07:24 +0100
From: sebb <sebbaz@gmail.com>
To: general@incubator.apache.org
Subject: Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release
 distribution channels like the central Maven repository]
In-Reply-To: <af2843cd0809181100i5eef7c33k27f565a0ce4431a6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <fbdc6a970809161549r11bbcf8ewf3808ac3ee224112@mail.gmail.com>
	 <200809170657.47757.dkulp@apache.org>
	 <1221696340.25066.4.camel@forge.local>
	 <48D1AB65.2050603@rowe-clan.net>
	 <19e0530f0809171825k36681f7dqde8160e343c3d20@mail.gmail.com>
	 <48D1B1E8.3010700@rowe-clan.net>
	 <af2843cd0809180639u2f1b00acu1c42ef668c46c76f@mail.gmail.com>
	 <25aac9fc0809180759y797f8addx8812ea873ac7abcd@mail.gmail.com>
	 <af2843cd0809181100i5eef7c33k27f565a0ce4431a6@mail.gmail.com>

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