incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.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 20:36:22 GMT
On Thu, Sep 18, 2008 at 3:07 PM, sebb <sebbaz@gmail.com> wrote:
> 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.

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: 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
>
>



-- 
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


Mime
View raw message