RE: status of PGP support in Maven

[Noel J. Bergman]

Jason van Zyl wrote:

> Noel, your comments are completely out of whack with reality. You are
> asking Maven to enforce something that no one does. Pretty much
> almost no one.

> Checking PGP signatures is obviously not something the vast majority of
people do.

Really?  Try following the instructions at http://www.medibuntu.org/ for
adding the repository without adding the PGP key, and see how well it works.
Not that I am suggesting a single, centralized, master key for the entire
repository.  And, again, RedHat takes it so seriously that they shutdown
their distribution network when they had even the slightest concern that the
signing keys were compromised.

If you are saying that we don't have signed packages, I agree with you that
more projects should be signing.  I have signed JAMES releases for years.
But the problem is much worse when using Maven, since users haven't a clue
as to the provanance of the artifacts they don't even realize that they are
loading onto their systems.

In any event, this discussion should be moved to eithe repository@ or
[EMAIL PROTECTED]

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

Niklas Gustavsson wrote:

> Is the idea to do this in the POM or similar? Having something like:

Can we please move this discussion to [EMAIL PROTECTED] or
[EMAIL PROTECTED]

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

The current plugin stores the checksum in a checksum.txt file that
sits alongside of the pom.xml in the source code.

Doing it in separate file makes adding new checksums a little easier,
plus I'm not sure it would be valid to extend the pom XML schema in
the way you described.
Another reason that putting it in the pom might not be a good idea, is
that we also include all the checksums for transitive dependencies
that are not explicitly listed in the pom.


On Tue, Oct 7, 2008 at 10:13 AM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 3:21 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> Because we would be including the checksum in the source code of the
>> project that needs the dependency.
>
> Is the idea to do this in the POM or similar? Having something like:
>
>commons-lang
>commons-lang
>2.3
>ABC...123
>
>
> /niklas
>
> -
> 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]

Re: status of PGP support in Maven

[Niklas Gustavsson]

On Tue, Oct 7, 2008 at 3:21 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> Because we would be including the checksum in the source code of the
> project that needs the dependency.

Is the idea to do this in the POM or similar? Having something like:

commons-lang
commons-lang
2.3
ABC...123


/niklas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

On Mon, Oct 6, 2008 at 11:39 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 6, 2008 at 10:08 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>
>> There are maven plugins that can validate the checksums of 3rd party
>> dependencies.
>
> Uhhh... Call me stupid, but how can checksum solve anything other than
> assuring that the download worked?? AFAIK, Maven does not pick up the
> checksums from the "authorative" server and validates it against the
> mirrored one. Perhaps that has changed since "back then"... And even
> then, how hard can it be to get the same 1024/2048/65536/... bit
> checksum by modifying that many 'extra' or 'unused' bits?
>

Because we would be including the checksum in the source code of the
project that needs the dependency.  I guess I failed to say that the
checksum needs to a cryptographic checksum and not one of your CRC
variates.  That way it's computationally difficult to figure out which
bits you need to pad to get the same checksum.

So like I said, once you start doing that maven is about as secure as
any other build tool that we currently use at the ASF.

>
> Cheers
> Niclas
>
> -
> 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]

Re: status of PGP support in Maven

[William A. Rowe, Jr.]

Niclas Hedhman wrote:
> On Mon, Oct 6, 2008 at 10:08 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> 
>> There are maven plugins that can validate the checksums of 3rd party
>> dependencies.
> 
> Uhhh... Call me stupid, but how can checksum solve anything other than
> assuring that the download worked?? AFAIK, Maven does not pick up the
> checksums from the "authorative" server and validates it against the
> mirrored one. Perhaps that has changed since "back then"... And even
> then, how hard can it be to get the same 1024/2048/65536/... bit
> checksum by modifying that many 'extra' or 'unused' bits?

You're not stupid[1][2].

Practically speaking, SHA384++ are still "strong enough" but as you point
out, unless the checksum values are taken from a trusted[3][4] reference
server separate from the distribution server, immune from mitm channels.

All of this is simply idle chatter until a repository server is compromised
at which point half will be scolding the other half "I told you so".  But
none of this has anything to do with "Incubator" best practices, unless
you want to prohibit incubator projects from assembling releases from Maven.

[1] http://en.wikipedia.org/wiki/Md5#Vulnerability
[2] http://en.wikipedia.org/wiki/Sha1#Cryptanalysis_and_validation
[3] http://www.apache.org/info/20010519-hack.html
[4] http://news.cnet.com/8301-1009_3-10023565-83.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Jason van Zyl]

On 6-Oct-08, at 10:21 AM, Noel J. Bergman wrote:


Niclas Hedhman wrote:


Being in the camp "I hate Maven too"


I hate Maven's lack of authentication, the potential for widespread  
damage,
and am immensely frustrated by their *years* of willfully negligent  
handling

thereof.


I would like to swap Noel's statement around and ask; Why doesn't
security concerned individuals participate in the Maven effort?
Lead by example and not by bashing...


They have received constructive input for years.  They continue to  
do so.
Jason's comments appear to echo the old-school negligence that I'd  
hoped the

Maven PMC was at long last starting to be cured of.



Noel, your comments are completely out of whack with reality. You are  
asking Maven to enforce something that no one does. Pretty much almost  
no one.


Downloads from our own servers:

   57.47%  archive.apache.org
   40.72%  www.apache.org

 ... almost all are zip's and [.tar].gz's (see extensions report)

   92.72%  .zip [Zip archives]
2.10%  .gz [Gzip compressed files]
2.05%  .tar.gz [Compressed archives]
   < 0.1%  .asc (not even listed)

Almost no one is validating PGP signatures. It's not that we couldn't  
in the past, we just had to choose to implement features that  
delivered what our users wanted. Checking PGP signatures is obviously  
not something the vast majority of people do. So pointing your finger  
at us and calling it negligence is not even remotely correct. The same  
goes the checksums which people also don't check but Maven does this  
automatically so we are, in fact, providing a greater degree of  
security to the average user. By default as a big warning message  
appears and you can optionally fail builds if the checksum fails.


After having a discussion with Henk about the nature of PGP usage and  
checksums I share his sentiments which he has allowed me to quote:


 -- In the past I have maintained that the most important reason to
sign stuff is to protect the /ASF/ (as opposed to downloaders).
People trust the ASF to detect malware (trojans etc) and react
upon detection. For downloaders, a simple md5 check should be
sufficient. The ASF should be as cautious/suspicious as the
most cautious/suspicious downloader imaginable. Are we ?

 -- Another reason: one day some computer science class is going
to compare various open-software centers (like the ASF) on
how well such centers protect themselves against malware.
The ASF should be examplary. Are we ?

When Mercury is integrated into Maven and people can optionally fail  
builds on failed PGP sig validation Maven will again provide a greater  
degree of security given that the practice of validating sigs is  
pretty much non-existent.




--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition

Re: status of PGP support in Maven

[Niclas Hedhman]

On Mon, Oct 6, 2008 at 10:08 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote:

> There are maven plugins that can validate the checksums of 3rd party
> dependencies.

Uhhh... Call me stupid, but how can checksum solve anything other than
assuring that the download worked?? AFAIK, Maven does not pick up the
checksums from the "authorative" server and validates it against the
mirrored one. Perhaps that has changed since "back then"... And even
then, how hard can it be to get the same 1024/2048/65536/... bit
checksum by modifying that many 'extra' or 'unused' bits?


Cheers
Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Henning Schmiedehausen]

On Mon, 2008-10-06 at 10:21 -0400, Noel J. Bergman wrote:
> Henning Schmiedehausen wrote:
> 
> > Noel J. Bergman wrote:
> > > We don't have to.  We can simply mandate that every ASF project sign
> their
> > > artifacts and charge the Maven PMC with enforcing it.
> 
> > No. The Maven PMC is charged with developing software for the Apache
> > Maven project.
> 
> You misunderstand.  I mean that the Maven code should enforce
> authentication, not that the Maven PMC must police the repository.

Maven is a modular framework. If you want to enforce such policy, it
should be possible to write plugins to do so. All that is needed is
someone to write them or fund writing. The current Maven group seems to
feel that they don't need them or they are not high on the prio list. So
someone else must do it. This is a do-ocracy. :-) 

> 
> > If we really want to put a distribution policy in place
> > and enforce it, I can see us creating a repository PMC which does this
> 
> We already have that as a subgroup of Infrastructure.  The
> [EMAIL PROTECTED] list has existed for *years*.

I know. So why are you bashing the Maven PMC when you mean the
"repository management group"? 

Ciao
Henning




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

Note that problem A and B both occur at manual steps in the
build/development process.
Just wanted to point that out to folks who complain that maven is
insecure because it downloads stuff automatically.

With checksums, as long as the manual steps are secure, automated bits
should be secure too.

Regards,
Hiram

> There are maven plugins that can validate the checksums of 3rd party
> dependencies.  Works well as long as:
> A) You can trust that your apache-baz-1.0 source has not been tampered with.
> B) The dependency had not been tampered with at the time that the
> dependency was first added to the build.  (Since that's when the
> expected checksum is calculated)
>
> Problem A: is universal to all builds at apache even if it's a maven
> based or make based build.  I guess this is what the GPG discussion is
> about.
> Problem B: Could be further reduced if the 3rd party used some type
> signing to help the apache developers validate that the 3rd party
> artifact is indeed authentic.
>
> If dependency checksum validation was encouraged by all our source
> builds, I think Problem B would become even less of a problem because
> you would get a network effect between all the source builds.  As more
> more projects add a 3rd party dependency validated by a checksum, it
> becomes harder to exploit that 3rd party dependency as the artifact
> checksum gets checked by more and more builds.  Tampering with the
> artifact would result some builds builds breaking and folks
> investigating the tampering.  Therefore the most effective way to
> tamper with a 3rd party artifact would be to do it when the 3rd party
> artifact first gets deployed.  So in effect we reduce the
> vulnerability window that exploits are effective in, which I think
> helps.
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>



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

RE: status of PGP support in Maven

[Noel J. Bergman]

Niclas Hedhman wrote:

> Being in the camp "I hate Maven too"

I hate Maven's lack of authentication, the potential for widespread damage,
and am immensely frustrated by their *years* of willfully negligent handling
thereof.

> I would like to swap Noel's statement around and ask; Why doesn't
> security concerned individuals participate in the Maven effort?
> Lead by example and not by bashing...

They have received constructive input for years.  They continue to do so.
Jason's comments appear to echo the old-school negligence that I'd hoped the
Maven PMC was at long last starting to be cured of.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

Henning Schmiedehausen wrote:

> Noel J. Bergman wrote:
> > We don't have to.  We can simply mandate that every ASF project sign
their
> > artifacts and charge the Maven PMC with enforcing it.

> No. The Maven PMC is charged with developing software for the Apache
> Maven project.

You misunderstand.  I mean that the Maven code should enforce
authentication, not that the Maven PMC must police the repository.

> If we really want to put a distribution policy in place
> and enforce it, I can see us creating a repository PMC which does this

We already have that as a subgroup of Infrastructure.  The
[EMAIL PROTECTED] list has existed for *years*.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

On Fri, Oct 3, 2008 at 8:01 PM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> On Fri, 2008-10-03 at 11:20 -0400, Noel J. Bergman wrote:
>> Henning Schmiedehausen wrote:
>>
>> > There is a pretty nice proposal on
>> > http://people.apache.org/~henkp/trust/, however this will again take a
>> > piece of "freedom of doing software at Apache" away and introduce some
>> > administrative overhead that all projects must implement and manage.
>>
>> But, as you say, it is worth doing something, whether exactly that or not,
>> because
>>
>> > Formalizing the signing of our releases would be a huge step towards a
>> > reliable validation for the Apache software releases.
>>
>> > It still does not help you with third-party releases, though.
>>
>> Is it our problem if you mean a third party, e.g., IBM, releasing our code
>> as part of their own commercial product?
>
> Actually I meant verifying/validating the third party dependencies that
> Apache projects *use*. So even if we go through all the pains of making
> sure that our users really get "apache-baz-1.0", it might just pull in
> "some-random-dependency-from-sourceforge-1.0" which can not be
> validated.
>
>Ciao
>Henning
>

There are maven plugins that can validate the checksums of 3rd party
dependencies.  Works well as long as:
A) You can trust that your apache-baz-1.0 source has not been tampered with.
B) The dependency had not been tampered with at the time that the
dependency was first added to the build.  (Since that's when the
expected checksum is calculated)

Problem A: is universal to all builds at apache even if it's a maven
based or make based build.  I guess this is what the GPG discussion is
about.
Problem B: Could be further reduced if the 3rd party used some type
signing to help the apache developers validate that the 3rd party
artifact is indeed authentic.

If dependency checksum validation was encouraged by all our source
builds, I think Problem B would become even less of a problem because
you would get a network effect between all the source builds.  As more
more projects add a 3rd party dependency validated by a checksum, it
becomes harder to exploit that 3rd party dependency as the artifact
checksum gets checked by more and more builds.  Tampering with the
artifact would result some builds builds breaking and folks
investigating the tampering.  Therefore the most effective way to
tamper with a 3rd party artifact would be to do it when the 3rd party
artifact first gets deployed.  So in effect we reduce the
vulnerability window that exploits are effective in, which I think
helps.

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

Re: status of PGP support in Maven

[Niclas Hedhman]

On Mon, Oct 6, 2008 at 10:45 AM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> On Fri, 2008-10-03 at 12:31 -0400, Noel J. Bergman wrote:
>>
>> We don't have to.  We can simply mandate that every ASF project sign their
>> artifacts and charge the Maven PMC with enforcing it.
>
> No. The Maven PMC is charged with developing software for the Apache
> Maven project. If we really want to put a distribution policy in place
> and enforce it, I can see us creating a repository PMC which does this
> (and talk to Maven about the features that they would like to see or
> (gasp!) implement them and contribute them back to Maven. I would see
> such a PMC as part of or collaborating with Infrastructure.

I thought this effort was started years and years ago...

> Maven is a piece of software, not a distribution mechanism. They just
> happen to build it because no one else did.
>
>> And perhaps now you start to gain a glimer of the depth of the problem
>> created by Maven's irresponsible, unconscionable, lackadaisical, attitude
>> towards security, despite other repository exemplars (e.g., linux
>> distributions), having had security in place for years.  Yes, it may be a
>
> Please stop it, Noel. This is not constructive.

Being in the camp "I hate Maven too", I must say I agree with Henning
that the language used was inappropriate.

I would like to swap Noel's statement around and ask; Why doesn't
security concerned individuals participate in the Maven effort? Lead
by example and not by bashing...


Cheers
Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Henning Schmiedehausen]

On Fri, 2008-10-03 at 12:31 -0400, Noel J. Bergman wrote:
> 
> We don't have to.  We can simply mandate that every ASF project sign their
> artifacts and charge the Maven PMC with enforcing it.

No. The Maven PMC is charged with developing software for the Apache
Maven project. If we really want to put a distribution policy in place
and enforce it, I can see us creating a repository PMC which does this
(and talk to Maven about the features that they would like to see or
(gasp!) implement them and contribute them back to Maven. I would see
such a PMC as part of or collaborating with Infrastructure. 

Maven is a piece of software, not a distribution mechanism. They just
happen to build it because no one else did.

> And perhaps now you start to gain a glimer of the depth of the problem
> created by Maven's irresponsible, unconscionable, lackadaisical, attitude
> towards security, despite other repository exemplars (e.g., linux
> distributions), having had security in place for years.  Yes, it may be a

Please stop it, Noel. This is not constructive. 

Ciao
Henning




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Robert Burrell Donkin]

On Fri, Oct 3, 2008 at 10:02 PM, sebb <[EMAIL PROTECTED]> wrote:
> On 03/10/2008, Bruce Snyder <[EMAIL PROTECTED]> wrote:
>> On Fri, Oct 3, 2008 at 8:50 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>>
>> > Moved to the thread it belongs in ...
>>  >
>>  > Jason van Zyl wrote:
>>  >> Noel J. Bergman wrote:
>>  >> > Emmanuel Lecharny wrote:
>>   Better a bad decision than no decision, otherwise, soon, nobody will
>>   vote anymore...
>>  >>> Not really.  Consider that there appears to be a clear consensus
>>  >>> that if Maven were to fix the download situation, requiring that users
>>  >>> approve the user of Incubator artifacts, rather than transparently use
>>  >>> them,  many of the -1 would be +1.
>>  >
>>  >> That's unlikely to happen. We're not going to be implementing policy
>>  >> enforcement for you.
>>  >
>>  > We don't need for you to implement any "policy" other than the requirement
>>  > for users to approve authorized signing keys.  You simply need to 
>> implement
>>  > artifact signing and mandatory authorization, which is why I've moved this
>>  > to the thread Brett started for purposes of discussing signing.
>>
>>
>> I'm trying to understand why authorization should be mandatory? To my
>>  knowledge, only some of the Linux package management tools (apt, port,
>>  rpm, yum) verify signatures by default and in the event of failure,
>>  they allow you to continue without the key verification.
>>
>>  Also, I've actually spoken to a number of folks about GPG verification
>>  of artifacts over the last year and very few folks actually use this
>>  today.

GPG is very good for certain purposes. downstream packagers should
check signatures (and know how to do so safely) but for normal users,
checking SHA sums against the main site is probably better.

>>  > Did you not see what just happened to Redhat with respect to Fedora?  They
>>  > take artifact security seriously.  For a long time, it has appeared that
>>  > Maven does not, but I am hopeful now that mandatory authorization will
>>  > appear, so that I and others will not have to increase lobbying efforts to
>>  > have the Maven repository closed, at least with respect to ASF projects.
>>
>>
>> Please explain what happened to RedHat with respect to Fedora. I'm not
>>  familiar with the situation.
>
> http://rtfa.net/2008/08/25/fedora-package-signing-server-compromise-crls-and-trust/
>
> and
>
> http://rhn.redhat.com/errata/RHSA-2008-0855.html

silver bullets don't work :-)

single key, single point of failure, single compromise required

sounds like it was picked up by their auditing system, though

BTW the RAT auditing stuff seems to be working ok now for the
incubator releases. if anyone wants to extend auditing to other
projects, i'd be happy to help.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Henning Schmiedehausen]

On Fri, 2008-10-03 at 11:20 -0400, Noel J. Bergman wrote:
> Henning Schmiedehausen wrote:
> 
> > There is a pretty nice proposal on
> > http://people.apache.org/~henkp/trust/, however this will again take a
> > piece of "freedom of doing software at Apache" away and introduce some
> > administrative overhead that all projects must implement and manage.
> 
> But, as you say, it is worth doing something, whether exactly that or not,
> because
> 
> > Formalizing the signing of our releases would be a huge step towards a
> > reliable validation for the Apache software releases.
> 
> > It still does not help you with third-party releases, though.
> 
> Is it our problem if you mean a third party, e.g., IBM, releasing our code
> as part of their own commercial product?

Actually I meant verifying/validating the third party dependencies that
Apache projects *use*. So even if we go through all the pains of making
sure that our users really get "apache-baz-1.0", it might just pull in
"some-random-dependency-from-sourceforge-1.0" which can not be
validated.

Ciao
Henning



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[sebb]

On 03/10/2008, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 3, 2008 at 8:50 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>
> > Moved to the thread it belongs in ...
>  >
>  > Jason van Zyl wrote:
>  >> Noel J. Bergman wrote:
>  >> > Emmanuel Lecharny wrote:
>   Better a bad decision than no decision, otherwise, soon, nobody will
>   vote anymore...
>  >>> Not really.  Consider that there appears to be a clear consensus
>  >>> that if Maven were to fix the download situation, requiring that users
>  >>> approve the user of Incubator artifacts, rather than transparently use
>  >>> them,  many of the -1 would be +1.
>  >
>  >> That's unlikely to happen. We're not going to be implementing policy
>  >> enforcement for you.
>  >
>  > We don't need for you to implement any "policy" other than the requirement
>  > for users to approve authorized signing keys.  You simply need to implement
>  > artifact signing and mandatory authorization, which is why I've moved this
>  > to the thread Brett started for purposes of discussing signing.
>
>
> I'm trying to understand why authorization should be mandatory? To my
>  knowledge, only some of the Linux package management tools (apt, port,
>  rpm, yum) verify signatures by default and in the event of failure,
>  they allow you to continue without the key verification.
>
>  Also, I've actually spoken to a number of folks about GPG verification
>  of artifacts over the last year and very few folks actually use this
>  today.
>
>
>  > Did you not see what just happened to Redhat with respect to Fedora?  They
>  > take artifact security seriously.  For a long time, it has appeared that
>  > Maven does not, but I am hopeful now that mandatory authorization will
>  > appear, so that I and others will not have to increase lobbying efforts to
>  > have the Maven repository closed, at least with respect to ASF projects.
>
>
> Please explain what happened to RedHat with respect to Fedora. I'm not
>  familiar with the situation.

http://rtfa.net/2008/08/25/fedora-package-signing-server-compromise-crls-and-trust/

and

http://rhn.redhat.com/errata/RHSA-2008-0855.html

>  Bruce
>  --
>  perl -e 'print unpack("u30","D0G)[EMAIL 
> PROTECTED]&5R\"F)R=6-E+G-N>61E  );'
>
>  Apache ActiveMQ - http://activemq.org/
>  Apache Camel - http://activemq.org/camel/
>  Apache ServiceMix - http://servicemix.org/
>
>  Blog: http://bruceblog.org/
>
>
>  -
>  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]

Re: status of PGP support in Maven

[Bruce Snyder]

On Fri, Oct 3, 2008 at 8:50 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Moved to the thread it belongs in ...
>
> Jason van Zyl wrote:
>> Noel J. Bergman wrote:
>> > Emmanuel Lecharny wrote:
 Better a bad decision than no decision, otherwise, soon, nobody will
 vote anymore...
>>> Not really.  Consider that there appears to be a clear consensus
>>> that if Maven were to fix the download situation, requiring that users
>>> approve the user of Incubator artifacts, rather than transparently use
>>> them,  many of the -1 would be +1.
>
>> That's unlikely to happen. We're not going to be implementing policy
>> enforcement for you.
>
> We don't need for you to implement any "policy" other than the requirement
> for users to approve authorized signing keys.  You simply need to implement
> artifact signing and mandatory authorization, which is why I've moved this
> to the thread Brett started for purposes of discussing signing.

I'm trying to understand why authorization should be mandatory? To my
knowledge, only some of the Linux package management tools (apt, port,
rpm, yum) verify signatures by default and in the event of failure,
they allow you to continue without the key verification.

Also, I've actually spoken to a number of folks about GPG verification
of artifacts over the last year and very few folks actually use this
today.

> Did you not see what just happened to Redhat with respect to Fedora?  They
> take artifact security seriously.  For a long time, it has appeared that
> Maven does not, but I am hopeful now that mandatory authorization will
> appear, so that I and others will not have to increase lobbying efforts to
> have the Maven repository closed, at least with respect to ASF projects.

Please explain what happened to RedHat with respect to Fedora. I'm not
familiar with the situation.

Bruce
-- 
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/

Blog: http://bruceblog.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Jukka Zitting]

Hi,

On Fri, Oct 3, 2008 at 4:50 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> We don't need for you to implement any "policy" other than the requirement
> for users to approve authorized signing keys.  You simply need to implement
> artifact signing and mandatory authorization, which is why I've moved this
> to the thread Brett started for purposes of discussing signing.

This part of the discussion IMHO doesn't belong here in the Incubator.

You want artifact signing and verification so you can enforce users to
explicitly acknowledge the use of incubating dependencies. I say such
click through is not and should not be needed.

Could we please keep the discussion on that policy decision (click
through or no click through) instead of wondering when and how Maven
will support that out of the box.

BR,

Jukka Zitting

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[sebb]

On 03/10/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
>  >We don't have to.  We can simply mandate that every ASF project sign
>  their
>  >artifacts and charge the Maven PMC with enforcing it.
>
>
> And are you going to lobby FireFox and Microsoft to enforce in their
>  browsers?

Microsoft already *does* check signatures for ActiveX addons.

>  Seriously why is this Maven's problem simply because it
>  downloads it when you can't enforce this in any other method that people
>  download it?
>

There is a big difference between using a browser to download a
specific file chosen by the user and Maven downloading some file
automatically.

>
>  >On the other hand, imagine the fun when
>  >someone puts a nice bit of malware into the security-free zone known as
>  the
>  >Maven repository.
>
>
> Security Free?
>
>
>  -
>  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]

RE: status of PGP support in Maven

[Brian E. Fox]

>We don't have to.  We can simply mandate that every ASF project sign
their
>artifacts and charge the Maven PMC with enforcing it.

And are you going to lobby FireFox and Microsoft to enforce in their
browsers? Seriously why is this Maven's problem simply because it
downloads it when you can't enforce this in any other method that people
download it?


>On the other hand, imagine the fun when
>someone puts a nice bit of malware into the security-free zone known as
the
>Maven repository.  

Security Free?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Jason van Zyl]

On 3-Oct-08, at 12:31 PM, Noel J. Bergman wrote:


Jason van Zyl wrote:


Noel J. Bergman wrote:

We don't need for you to implement any "policy" other than the
requirement for users to approve authorized signing keys.  You
simply need to  implement artifact signing and mandatory
authorization, which is why I've moved this to the thread Brett
started for purposes of discussing signing.



You are not the Incubator PMC


And where did I imply otherwise??

and what the Incubator says they require is far from clear.  
Disclaimers,

notices, PGP keys. No one  knows what anyone wants here. No one
can follow these discussions.


That's rather over the top.


We're talking years here Noel. Point at anything that succinctly  
states the policy. Doesn't exist. I think if you asked anyone right  
now they would have no idea what the result is. We had a majority  
vote, someone on the board said that's the way we should go, some  
agree, some don't, then you step in and say that's not the way it is  
because Greg said that's the way it is. It's not meant to be over the  
top, just a statement of fact.



The disclaimer and notice requirements are well
documented and have been for a long time.  The PGP key situation is  
under
discussion, likely to be resolved by the Infrastructure Team, and  
will be an

ASF-wide issue.  The Incubator relationship is that the same mandatory
requirement for security that needs to be imposed on Maven can also  
address
the long-standing requirement that users be aware of and accepting  
that they

are using Incubator artifacts.


You won't be imposing anything on Maven and what we do with central or  
what security measures we do, or do not implement. Policy here is, of  
course, of the IPMC. Turn on/off repositories as you see fit. It's got  
nothing to do with the way Maven users access the central repository.  
If you don't want to participate directly making artifacts available  
then don't.


We're not fighting you, and technically we've made it easier for folks  
to check if there are signatures but lots of projects don't and that's  
not Maven's problem, it's not Ivy's problem, it's not BuildR's problem.






Oleg, who is responsible for implementing Mercury which has
full PGP support, has this functionality working on all branches of
Maven but the option to use it will be in the hands of the user. As
the quality and tools for supporting PGP get better, and more people
use them we will again take a look at the default behavior.



Did you not see what just happened to Redhat with respect to
Fedora?  They take artifact security seriously.  For a long time,
it has appeared that Maven does not, but I am hopeful now that
mandatory authorization will appear, so that I and others will not
have to increase lobbying efforts to have the Maven repository
closed, at least with respect to ASF projects.


How are you going to stop people from [creating their own artifacts  
and

repositories] Noel when its their right?

We don't have to.  We can simply mandate that every ASF project sign  
their

artifacts and charge the Maven PMC with enforcing it.


The first part is already mandated, or I certainly thought it was. The  
second part of that is not going to happen.





And perhaps now you start to gain a glimer of the depth of the problem
created by Maven's irresponsible, unconscionable, lackadaisical,  
attitude

towards security, despite other repository exemplars (e.g., linux
distributions), having had security in place for years.  Yes, it may  
be a
bit painful to make the change.  On the other hand, imagine the fun  
when
someone puts a nice bit of malware into the security-free zone known  
as the
Maven repository.  Not only do I agree with Henning's assessment, I  
think

that network administrators should block the Maven repository at their
firewalls.


Tell them that. See what they do.




--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

We all have problems. How we deal with them is a measure of our worth.

 -- Unknown


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Robert Burrell Donkin]

On Fri, Oct 3, 2008 at 5:31 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Jason van Zyl wrote:
>
>> Noel J. Bergman wrote:



>> > Did you not see what just happened to Redhat with respect to
>> > Fedora?  They take artifact security seriously.  For a long time,
>> > it has appeared that Maven does not, but I am hopeful now that
>> > mandatory authorization will appear, so that I and others will not
>> > have to increase lobbying efforts to have the Maven repository
>> > closed, at least with respect to ASF projects.
>
>> How are you going to stop people from [creating their own artifacts and
> repositories] Noel when its their right?
>
> We don't have to.  We can simply mandate that every ASF project sign their
> artifacts and charge the Maven PMC with enforcing it.

sounds very reasonsable

> And perhaps now you start to gain a glimer of the depth of the problem
> created by Maven's irresponsible, unconscionable, lackadaisical, attitude
> towards security, despite other repository exemplars (e.g., linux
> distributions), having had security in place for years.

that's probably a little strong

many distros have only really addressed this in the last year or so,
and even then their solutions are far from perfect

IMO a combination of approaches is require to deliver good defense in
depth combining auditing, automatic signing, publication and wide
dissemination of results together with signatures by release managers.

this is also something that may well be best solved in a common forum.
it would be very useful to reach out to other organisations such as
fedora, debian, eclipse, java.net etc which have similiar problems.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Robert Burrell Donkin]

On Sat, Sep 20, 2008 at 6:08 PM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
>> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
>> <[EMAIL PROTECTED]> wrote:
>> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> >> How about we include the signatures in the source distros?  That way
>> >> if you trust your source, then you can trust the dependencies it
>> >> downloads.
>> >
>> > Eww.  That'd be a giant gaping security hole.
>>
>> not necessarily, depends how it's done
>>
>> signing works through trusting the people who own the keys. given
>> sufficient signaturees (to prevent small conspiracies), where the
>> signatures are downloaded from shouldn't matter.
>
> Hiram suggested to put the signatures into the source, which in turn is
> also distributed from the repo. If you compromise the repo and change
> the artifact, it is trivial to update the source artifact to contain a
> matching signature.

AIUI it is not sufficient to gain access to the source. forging a
signature without the private key is not feasible.

therefore, a feasible attack means using a private key trusted to sign
incubator releases that has been unknowingly compromised or using a
rogue incubator release manager. it should be possible to provide
defense against these attacks by using signatures from a sufficient
number of keys.

> This is a security hole. And I don't really care for some of the
> proposed "high nineties" security solutions. Either a solution is secure
> or it is not. Everything else is just FUD.

public key cryptography cannot guarantee absolute security. security
measure only protect against particular attack vectors. no solution is
toyally secure.

IMHO the best approach is defense in depth with good protection
against all known attack vectors

> The problem with the central repo is that you need an easy accessible
> web of trust if you want validation. The Apache web of trust is
> distributed and an overlay to the GPG web of trust. But if you live in
> Juneau, Alaska, it is hard for you to access it and get a trust
> relationship to it.

WOT is about personal identity and is not role based. the apache WOT
allows other members to trust that the owner of the private key is in
fact the 'Robert Burrell Donkin' listed in the members list.

release validation is quite a different notion of trust. just because
a release has been signed by someone called 'Robert Donkin' does not
mean that it can be trusted. perhaps it is some other individual or
perhaps i signed something with another key rather than my 'CODE
SIGNING KEY'.

what is required is a role-based notion of trust: that a particular
key is trusted to sign incubator releases for a particular podling.
this does not require a link through the WOT.

having said all that, i believe that apache as an organisation
*really* needs a better WOT so that *we* can verify our own releases.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

Jason van Zyl wrote:

> Noel J. Bergman wrote:
> > We don't need for you to implement any "policy" other than the
> > requirement for users to approve authorized signing keys.  You
> > simply need to  implement artifact signing and mandatory
> > authorization, which is why I've moved this to the thread Brett
> > started for purposes of discussing signing.

> You are not the Incubator PMC

And where did I imply otherwise??

> and what the Incubator says they require is far from clear. Disclaimers,
> notices, PGP keys. No one  knows what anyone wants here. No one
> can follow these discussions.

That's rather over the top.  The disclaimer and notice requirements are well
documented and have been for a long time.  The PGP key situation is under
discussion, likely to be resolved by the Infrastructure Team, and will be an
ASF-wide issue.  The Incubator relationship is that the same mandatory
requirement for security that needs to be imposed on Maven can also address
the long-standing requirement that users be aware of and accepting that they
are using Incubator artifacts.

> Oleg, who is responsible for implementing Mercury which has
> full PGP support, has this functionality working on all branches of
> Maven but the option to use it will be in the hands of the user. As
> the quality and tools for supporting PGP get better, and more people
> use them we will again take a look at the default behavior.

> > Did you not see what just happened to Redhat with respect to
> > Fedora?  They take artifact security seriously.  For a long time,
> > it has appeared that Maven does not, but I am hopeful now that
> > mandatory authorization will appear, so that I and others will not
> > have to increase lobbying efforts to have the Maven repository
> > closed, at least with respect to ASF projects.

> How are you going to stop people from [creating their own artifacts and
repositories] Noel when its their right?

We don't have to.  We can simply mandate that every ASF project sign their
artifacts and charge the Maven PMC with enforcing it.

And perhaps now you start to gain a glimer of the depth of the problem
created by Maven's irresponsible, unconscionable, lackadaisical, attitude
towards security, despite other repository exemplars (e.g., linux
distributions), having had security in place for years.  Yes, it may be a
bit painful to make the change.  On the other hand, imagine the fun when
someone puts a nice bit of malware into the security-free zone known as the
Maven repository.  Not only do I agree with Henning's assessment, I think
that network administrators should block the Maven repository at their
firewalls.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Jason van Zyl]

On 3-Oct-08, at 10:50 AM, Noel J. Bergman wrote:


Moved to the thread it belongs in ...

Jason van Zyl wrote:

Noel J. Bergman wrote:

Emmanuel Lecharny wrote:
Better a bad decision than no decision, otherwise, soon, nobody  
will

vote anymore...

Not really.  Consider that there appears to be a clear consensus
that if Maven were to fix the download situation, requiring that  
users
approve the user of Incubator artifacts, rather than transparently  
use

them,  many of the -1 would be +1.



That's unlikely to happen. We're not going to be implementing policy
enforcement for you.


We don't need for you to implement any "policy" other than the  
requirement
for users to approve authorized signing keys.  You simply need to  
implement
artifact signing and mandatory authorization, which is why I've  
moved this

to the thread Brett started for purposes of discussing signing.


You are not the Incubator PMC, and what the Incubator says they  
require is far from clear. Disclaimers, notices, PGP keys. No one  
knows what anyone wants here. No one can follow these discussions.


There will be no mandatory authorization. That will not be turned on  
by default in the foreseeable future. The tools will exist for people  
to use as they see fit. It is more likely that people using repository  
managers will enable this, but it won't be turned on in the Maven  
client. Oleg, who is responsible for implementing Mercury which has  
full PGP support, has this functionality working on all branches of  
Maven but the option to use it will be in the hands of the user. As  
the quality and tools for supporting PGP get better, and more people  
use them we will again take a look at the default behavior





Did you not see what just happened to Redhat with respect to  
Fedora?  They
take artifact security seriously.  For a long time, it has appeared  
that

Maven does not, but I am hopeful now that mandatory authorization will
appear, so that I and others will not have to increase lobbying  
efforts to
have the Maven repository closed, at least with respect to ASF  
projects.


Lobby away. Close the repository, then what's going to happen? Someone  
checks out all the sources with a CI system, builds everything and  
publishes them, then what are you going to do? Shut down anonymous SVN  
access because people are doing what they can by rights of the  
license? Track them down and tell them not to do it? Tell the Maven  
PMC to intervene to stop people from making submissions via JIRA. Stop  
the repositories that are already syncing Apache artifacts to central  
or hosting their own repositories? How are you going to stop people  
from doing this Noel when its their right? You going to lock down  
everything to the point where no one wants to get involved?





--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

We know what we are, but know not what we may be.

  -- Shakespeare


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

Hiram wrote:
> a source build like Apache ServiceMix depends on hundreds of
> third party dependencies.. so an end user would need to end up
> trusting LOTs different signatures to get ServiceMix to build.

> It would be easier if the end user could just trust the Apache source
> distro and also transitively trust the signatures that we trust for
> our dependencies.

A signature is a signed digest.

One way of addressing your issue would be to allow you to include your own
signatures (signed digests) for your downstream dependencies.  If I trust
your package, I will trust your signed digests, and therefore if the decoded
digests match the downstream artifact, that would be deemed OK in this
scenario.

This would mean having to recheck artifacts for each dependent project,
since I cannot trust dependent D for project B just because I trusted it for
project A.  Project A might have been released specifically in order to have
me accept a trojan dependency.

This is off-the-cuff, and definitely subject to amendment if not outright
retraction if/when Henning et al shoot holes in it.  :-)

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

Henning Schmiedehausen wrote:

> There is a pretty nice proposal on
> http://people.apache.org/~henkp/trust/, however this will again take a
> piece of "freedom of doing software at Apache" away and introduce some
> administrative overhead that all projects must implement and manage.

But, as you say, it is worth doing something, whether exactly that or not,
because

> Formalizing the signing of our releases would be a huge step towards a
> reliable validation for the Apache software releases.

> It still does not help you with third-party releases, though.

Is it our problem if you mean a third party, e.g., IBM, releasing our code
as part of their own commercial product?

> IMHO: Anyone who is using maven for commercial software development and
> does not run a controlled, in-house repository that is actively managed
> and maintained is IMHO in for big, ugly surprises in the long run.

+1  Unfortunately, I believe that you'd be taking about a "high 9s"
percentage of the population of Maven users who do NOT follow that rule.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

> The sources you build come either from svn or from a signed
> release package.

We are concerned only with the latter, not what people do with code taken
directly from our SVN repository.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

Brett Porter wrote:

> Currently, it has checking turned on by default, but that isn't going to
be
> a reasonable setting for some releases to come until the signatures in the
> repository are cleaned up.

Why not enforce checking, but provide the ability for users to manually
approve unsigned artifacts?  Once you cache the downloaded artifact, you
should not have to approve from cache.

> For the releases to be identified as from the incubator, they'll need to
be
> signed solely by "the incubator". Did you want to elaborate on how you
> anticipated that set up working?

There are a variety of options, as have been discussed in this thread.  An
obvious, and overly simple, solution is a designated signing key for the
Incubator PMC, and we maintain strict control over the private key.  Just
having a naive WoT is insufficient, since while I might be authorized to
release for JAMES or the Incubator, I am not authorized to release for
Maven.

But Henning, Dw, Ben (Laurie), Justin and others have experience in this
area, and the details should probably be discussed on infrastructure-dev.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: status of PGP support in Maven

[Noel J. Bergman]

> Something else that needs to be considered is what happens if
> someone's private key in the web of trust gets compromised?

Did you see what happened with Fedora last week (or two weeks ago at this
point)?  They had to close down their repository system and re-issue new,
re-signed, artifacts.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

re: status of PGP support in Maven

[Noel J. Bergman]

Moved to the thread it belongs in ...

Jason van Zyl wrote:
> Noel J. Bergman wrote:
> > Emmanuel Lecharny wrote:
>>> Better a bad decision than no decision, otherwise, soon, nobody will
>>> vote anymore...
>> Not really.  Consider that there appears to be a clear consensus
>> that if Maven were to fix the download situation, requiring that users
>> approve the user of Incubator artifacts, rather than transparently use
>> them,  many of the -1 would be +1.

> That's unlikely to happen. We're not going to be implementing policy
> enforcement for you.

We don't need for you to implement any "policy" other than the requirement
for users to approve authorized signing keys.  You simply need to implement
artifact signing and mandatory authorization, which is why I've moved this
to the thread Brett started for purposes of discussing signing.

Did you not see what just happened to Redhat with respect to Fedora?  They
take artifact security seriously.  For a long time, it has appeared that
Maven does not, but I am hopeful now that mandatory authorization will
appear, so that I and others will not have to increase lobbying efforts to
have the Maven repository closed, at least with respect to ASF projects.

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[David Crossley]

William A. Rowe, Jr. wrote:
> 
> The bigger problem is that you appear to be arguing against solving the
> problem rather than offering solutions, and I recall some have suggested
> that this thread should die already.  Maybe time to take this to maven
> where it belongs?

I reckon that it is beyond Maven.

It is hard to know where this belongs. For a long
time we have needed a place to deal with cross-project
issues. Perhaps the new infrastructure-dev@ list.

-David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[William A. Rowe, Jr.]

Paul Querna wrote:
> 
> Open an infrastructure JIRA ticket and I'll figure out getting https://
> on www.apache.org sooner or later.

Good thought.  https://issues.apache.org/jira/browse/INFRA-1737

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Paul Querna]

William A. Rowe, Jr. wrote:

Henning Schmiedehausen wrote:

So you assume that that www.apache.org can not be hacked? What if a
signing key *IS* in KEYS but not signed by anyone (because the developer
has never attended an Apache key signing event)?


No, I answered your question.

W.r.t. www.apache.org/dist/{tlp}/KEYS, we have a serious issue to address,
because it's not https: accessible so cannot be trusted.  Yes, it's quite
possible to fetch https://svn.apache.org/repos/asf/{tlp}/{code}/trunk/KEYS
but that's not what we suggest, and suboptimal to boot.


Open an infrastructure JIRA ticket and I'll figure out getting https:// 
on www.apache.org sooner or later.


Thanks,

Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Dirk-Willem van Gulik]

On Sep 24, 2008, at 3:44 PM, Hiram Chirino wrote:


On Wed, Sep 24, 2008 at 1:27 AM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:

On Mon, 2008-09-22 at 13:42 -0400, Hiram Chirino wrote:

On Mon, Sep 22, 2008 at 10:12 AM, sebb <[EMAIL PROTECTED]> wrote:

On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote:
The only reason I suggested including the sigs in the source  
distro is
because a source build like Apache ServiceMix depends on  
hundreds of

third party dependencies.. so an end user would need to end up
trusting LOTs different signatures to get ServiceMix to build.

It would be easier if the end user could just trust the Apache  
source
distro and also transitively trust the signatures that we trust  
for

our dependencies.





I actually meant to say include the pub key for the dependency in  
the

source distro.


How do you validate that the pub key presented to you is genuine?  
What

you currently proposing is

src-artifact <- signed with A's privkey, validated with A's pubkey

A's pubkey is inside src-artifact.


NO I'm not.  I'm saying that A artifact has 100 dependencies by say 30
different signers.. we include
those 30 pub keys in the src-artifact.  NOT the A key!

You have to validate the A source distro the same way you would
validate an ANT based build source distro today.


Ok we can do something where the X +1's issued are sent to a keyserver  
along with the OK of a PMC member or human gate (as one does not want  
to also automate veto counting) or similar - together with the md5/ 
sha1. And returned is the later hash signed by some rolling apache key  
or x509.


Thanks,

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

On Wed, Sep 24, 2008 at 1:27 AM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-22 at 13:42 -0400, Hiram Chirino wrote:
>> On Mon, Sep 22, 2008 at 10:12 AM, sebb <[EMAIL PROTECTED]> wrote:
>> > On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> >> The only reason I suggested including the sigs in the source distro is
>> >>  because a source build like Apache ServiceMix depends on hundreds of
>> >>  third party dependencies.. so an end user would need to end up
>> >>  trusting LOTs different signatures to get ServiceMix to build.
>> >>
>> >>  It would be easier if the end user could just trust the Apache source
>> >>  distro and also transitively trust the signatures that we trust for
>> >>  our dependencies.
>> >>
>> >
>>
>> I actually meant to say include the pub key for the dependency in the
>> source distro.
>
> How do you validate that the pub key presented to you is genuine? What
> you currently proposing is
>
> src-artifact <- signed with A's privkey, validated with A's pubkey
>
> A's pubkey is inside src-artifact.

NO I'm not.  I'm saying that A artifact has 100 dependencies by say 30
different signers.. we include
those 30 pub keys in the src-artifact.  NOT the A key!

You have to validate the A source distro the same way you would
validate an ANT based build source distro today.


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

Re: status of PGP support in Maven

[Hiram Chirino]

On Wed, Sep 24, 2008 at 1:20 AM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-22 at 09:34 -0400, Hiram Chirino wrote:
>> The only reason I suggested including the sigs in the source distro is
>> because a source build like Apache ServiceMix depends on hundreds of
>> third party dependencies.. so an end user would need to end up
>
> Yes. Now you are getting closer.
>
>> trusting LOTs different signatures to get ServiceMix to build.
>
> Right. You already have to do that today. Only you don't do it. And you
> do trust Maven not to pull any compromised artifact as a four-levels
> removed dependency. IAW, you are already in that hell, only Maven hides
> it from you.
>
>> It would be easier if the end user could just trust the Apache source
>> distro and also transitively trust the signatures that we trust for
>> our dependencies.
>
> And that does not work. What is the "Apache source distro"? And whom do
> you trust? Consider the following case (if you look really, really
> close, you might find similarities to existing projects):
>
> The "Apache Foo" project has a stable release for a long time. This
> release was signed by a developer well connected to the Apache web of
> trust and so it was possible to somewhat verify that this distribution
> is genuine. The project went from stable to dormant. After two years, a
> new crop of committers was voted in and started to work on that project
> again. They decided to release a new and improved version, ran through
> all the Apache release process and the developer finall doing the
> release used his new, shiny and nice "[EMAIL PROTECTED] (Code Signing Key)"
> key to sign this release. However, as he never has visited an Apache
> Keysigning event yet and is BTW living in Juneau, Alaska, his key is not
> at all connected to the Apache web of trust. But this new version
> contains a number of bug fixes that the dependees have waited for a long
> long time. So they eagerly changed their Maven poms."
>

I fail to see how this is a maven problem.  Even if the build was ant
based, won't we have the same problem?  How do downstream users start
trusting new Apache Foo releases?  Even if you were using Ant or Make,
wouldn't the problem be identical if came from a maven repo or if it
was downloaded right from the Apache website?

How do we verify a non-maven source distro today with 100% assurance
it's not tampered with?

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

Re: status of PGP support in Maven

[William A. Rowe, Jr.]

Henning Schmiedehausen wrote:
> So you assume that that www.apache.org can not be hacked? What if a
> signing key *IS* in KEYS but not signed by anyone (because the developer
> has never attended an Apache key signing event)?

No, I answered your question.

W.r.t. www.apache.org/dist/{tlp}/KEYS, we have a serious issue to address,
because it's not https: accessible so cannot be trusted.  Yes, it's quite
possible to fetch https://svn.apache.org/repos/asf/{tlp}/{code}/trunk/KEYS
but that's not what we suggest, and suboptimal to boot.

The bigger problem is that you appear to be arguing against solving the
problem rather than offering solutions, and I recall some have suggested
that this thread should die already.  Maybe time to take this to maven
where it belongs?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Niclas Hedhman]

On Wed, Sep 24, 2008 at 2:02 PM, Henning Schmiedehausen
<[EMAIL PROTECTED]>wrote:

> There is a pretty nice proposal on
> http://people.apache.org/~henkp/trust/,
> however this will again take a
> piece of "freedom of doing software at Apache" away and introduce some
> administrative overhead that all projects must implement and manage.


One paragraph for you;  ;-)

http://people.apache.org/~henkp/trust/#tag_6


Cheers
Niclas

Re: status of PGP support in Maven

[Henning Schmiedehausen]

There is a pretty nice proposal on
http://people.apache.org/~henkp/trust/, however this will again take a
piece of "freedom of doing software at Apache" away and introduce some
administrative overhead that all projects must implement and manage.

Formalizing the signing of our releases would be a huge step towards a
reliable validation for the Apache software releases. It still does not
help you with third-party releases, though.

I don't know how many artifacts are on repo. I'd guess hundreds,
probably thousands. They have all been uploaded automatically or
semi-automatically. Because validating them by hand from the bazillion
of different sources is very difficult.

I spot a startup chance here for a company offering a trusted, validated
repository where all uploaded artifacts have been verified by the
uploaders. Any VCs around? I am bored and have time to write a business
plan ;-) 

IMHO: Anyone who is using maven for commercial software development and
does not run a controlled, in-house repository that is actively managed
and maintained is IMHO in for big, ugly surprises in the long run.

Ciao
Henning


On Wed, 2008-09-24 at 13:36 +0800, Niclas Hedhman wrote:
> On Wed, Sep 24, 2008 at 1:20 PM, Henning Schmiedehausen
> <[EMAIL PROTECTED]>wrote:
> I enjoy your scenarios...
> 
> 
> > And again, there is no "high nineties" security. Your solution is either
> > secure or it is not.
> 
> 
> For accuracy; This is not true either. AFAIK, no security solution is
> totally secure. You will be left with a number game.
> 
> 
> But I agree that this is a complex and non-trivial problem. Right now, we
> just say; "No Security, check manually." and to users who don't (like
> myself) we just ask them to blame themselves for being sloppy. Fair Enough.
> BUT, somehow I feel that a bit of "help" could be in order, and I think that
> if it is not portrayed as a "secure" and that the manual check should still
> be done by the security conscious, then why not try to provide that? How can
> a step in the right direction be bad?
> 
> 
> Cheers
> Niclas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Henning Schmiedehausen]

So you assume that that www.apache.org can not be hacked? What if a
signing key *IS* in KEYS but not signed by anyone (because the developer
has never attended an Apache key signing event)?

Ciao
Henning

On Wed, 2008-09-24 at 00:36 -0500, William A. Rowe, Jr. wrote:
> Henning Schmiedehausen wrote:
> > 
> > How do you validate that the pub key presented to you is genuine? 
> 
> Every project worth it's salt has a www.apache.org/dist/{tlp}/KEYS
> file which contain that project's contributors signatures, countersigned
> or not.  Ideally, they are extensively countersigned.  But in some cases
> they are not.
> 
> The delta is; are you trusting www.apache.org/dist/{tlp}/KEYS?  Or are
> you trusting www.friendlyname.zz/mirrors/apache/dist/{tlp}/KEYS?  There's
> a pretty major difference :)
> 
> 
> 
> 
> -
> 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]

Re: status of PGP support in Maven

[William A. Rowe, Jr.]

Henning Schmiedehausen wrote:
> 
> How do you validate that the pub key presented to you is genuine? 

Every project worth it's salt has a www.apache.org/dist/{tlp}/KEYS
file which contain that project's contributors signatures, countersigned
or not.  Ideally, they are extensively countersigned.  But in some cases
they are not.

The delta is; are you trusting www.apache.org/dist/{tlp}/KEYS?  Or are
you trusting www.friendlyname.zz/mirrors/apache/dist/{tlp}/KEYS?  There's
a pretty major difference :)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Niclas Hedhman]

On Wed, Sep 24, 2008 at 1:20 PM, Henning Schmiedehausen
<[EMAIL PROTECTED]>wrote:
I enjoy your scenarios...


> And again, there is no "high nineties" security. Your solution is either
> secure or it is not.


For accuracy; This is not true either. AFAIK, no security solution is
totally secure. You will be left with a number game.


But I agree that this is a complex and non-trivial problem. Right now, we
just say; "No Security, check manually." and to users who don't (like
myself) we just ask them to blame themselves for being sloppy. Fair Enough.
BUT, somehow I feel that a bit of "help" could be in order, and I think that
if it is not portrayed as a "secure" and that the manual check should still
be done by the security conscious, then why not try to provide that? How can
a step in the right direction be bad?


Cheers
Niclas

Re: status of PGP support in Maven

[Henning Schmiedehausen]

On Mon, 2008-09-22 at 13:42 -0400, Hiram Chirino wrote:
> On Mon, Sep 22, 2008 at 10:12 AM, sebb <[EMAIL PROTECTED]> wrote:
> > On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> >> The only reason I suggested including the sigs in the source distro is
> >>  because a source build like Apache ServiceMix depends on hundreds of
> >>  third party dependencies.. so an end user would need to end up
> >>  trusting LOTs different signatures to get ServiceMix to build.
> >>
> >>  It would be easier if the end user could just trust the Apache source
> >>  distro and also transitively trust the signatures that we trust for
> >>  our dependencies.
> >>
> >
> 
> I actually meant to say include the pub key for the dependency in the
> source distro.

How do you validate that the pub key presented to you is genuine? What
you currently proposing is

src-artifact <- signed with A's privkey, validated with A's pubkey

A's pubkey is inside src-artifact.

So you extract the pubkey from the src-artifact and use it to validate
that the src-artifact is really genuine.

(Bonus points for spotting the circle).

Alternative scenario:

bin-artifact <- signed with A's privkey, validated with A's pubkey

A's pubkey is inside src-artifact.

AIUI, you propose to download the src-artifact, extract the pubkey and
validate that the bin-artifact is genuine.

How do you trust that the src-artifact was not tampered with?

Ciao
Henning




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Henning Schmiedehausen]

On Mon, 2008-09-22 at 09:34 -0400, Hiram Chirino wrote:
> The only reason I suggested including the sigs in the source distro is
> because a source build like Apache ServiceMix depends on hundreds of
> third party dependencies.. so an end user would need to end up

Yes. Now you are getting closer.

> trusting LOTs different signatures to get ServiceMix to build.

Right. You already have to do that today. Only you don't do it. And you
do trust Maven not to pull any compromised artifact as a four-levels
removed dependency. IAW, you are already in that hell, only Maven hides
it from you.

> It would be easier if the end user could just trust the Apache source
> distro and also transitively trust the signatures that we trust for
> our dependencies.

And that does not work. What is the "Apache source distro"? And whom do
you trust? Consider the following case (if you look really, really
close, you might find similarities to existing projects): 

The "Apache Foo" project has a stable release for a long time. This
release was signed by a developer well connected to the Apache web of
trust and so it was possible to somewhat verify that this distribution
is genuine. The project went from stable to dormant. After two years, a
new crop of committers was voted in and started to work on that project
again. They decided to release a new and improved version, ran through
all the Apache release process and the developer finall doing the
release used his new, shiny and nice "[EMAIL PROTECTED] (Code Signing Key)"
key to sign this release. However, as he never has visited an Apache
Keysigning event yet and is BTW living in Juneau, Alaska, his key is not
at all connected to the Apache web of trust. But this new version
contains a number of bug fixes that the dependees have waited for a long
long time. So they eagerly changed their Maven poms."

How do you verify, that the release that Maven has just downloaded from
a maven repo mirror is really this new release and not a hacked one? 

Or worse: 

You have, for any reason, two different versions from two repo mirrors,
both are signed by "[EMAIL PROTECTED] (Code Signing Key)" with different
fingerprints. www.apache.org is down or unreachable (think airplane).
Which one do you trust? 

Another scenario: 

You have two different versions from two repo mirrors, both are signed
by "[EMAIL PROTECTED] (Code Signing Key)"  with the same fingerprint. 
Which one do you trust? [1]

a) When asking "[EMAIL PROTECTED]", he confesses that he lost an USB-stick
with his secret key a few months ago. He thought it fell from the ferry
last time he went back home to Juneau, Alaska and was lost. 
b) When asking "[EMAIL PROTECTED]", he confesses that he made a mistake
while cutting the release and quickly uploaded a corrected version. He
is reasonably sure, that no-one ever saw the first one.

None of these scenarios are invented. Each of them has happened in the
past (or is bound to happen at some point in the future). 

Face it: To get a *reliable* verification of signatures, an arbitrary
web of trust does not work. That is why trust centers have root
certificates and hand them out to browser distributors like candy. So
you have a base line that you can trust from an independent source. 

And again, there is no "high nineties" security. Your solution is either
secure or it is not. And the Jackpot of being able to open a backdoor in
*every* application around the planet that e.g. pulls in
commons-collections at some point through Maven is too good to assume
that it will never happen. Many banks use Java software. I'd assume that
every bank using Java software has a commons-collections or commons-lang
stashed away somewhere. 

> 
> The end user would still need to manually validate the source distro 
> signature.

I assume that only a very very small number of "end users" knows that
there is source code, will ever download it or knows how to verify it. 

Ciao
Henning

[1] For the answer "the one that is on www.apache.org/dist" will buy you
the question "So you assume that www.apache.org can not be hacked?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[sebb]

On 21/09/2008, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:
>
>  On Sat, 2008-09-20 at 19:52 +0200, Jukka Zitting wrote:
>  > HI,
>  >
>  > On Sat, Sep 20, 2008 at 7:08 PM, Henning Schmiedehausen
>  > <[EMAIL PROTECTED]> wrote:
>  > > Hiram suggested to put the signatures into the source, which in turn is
>  > > also distributed from the repo.
>  >
>  > It's not. The sources you build come either from svn or from a signed
>  > release package.
>
>
> What is a signed release package? If I can compromise the repository and
>  change signatures on an artifact, I can also change the signatures and
>  contents on a "signed release package". That does not work.
>
>  In <[EMAIL PROTECTED]>:
>
>  Hiram> How about we include the signatures in the source distros?  That
>  Hiram> way if you trust your source, then you can trust the dependencies
>  Hiram> it downloads.
>
>  Sounds pretty clear to me. Your suggestion again requires that the
>  verifier goes back to a central, trusted repository (Single point of
>  failure)

AIUI, the checksum list will be part of the release, which will be
signed. Therefore it cannot be changed unless the signature is
changed. Validating the signature on the release is an essential part
of the process.

That's no different from validating a standard release.

> and even more, it requires some sort of convention on where and
>  how to store these signatures. Does not scale.

However I totally agree with that.

>  Folks, if distributed trust was easy, Trust Centers wouldn't make a
>  fortune selling signed keys from a central trust source ("Root
>  certificate").
>
> Ciao
>
> Henning
>
>
>
>
>
>  -
>  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]

Re: status of PGP support in Maven

[sebb]

On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 22, 2008 at 10:12 AM, sebb <[EMAIL PROTECTED]> wrote:
>  > On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>  >> The only reason I suggested including the sigs in the source distro is
>  >>  because a source build like Apache ServiceMix depends on hundreds of
>  >>  third party dependencies.. so an end user would need to end up
>  >>  trusting LOTs different signatures to get ServiceMix to build.
>  >>
>  >>  It would be easier if the end user could just trust the Apache source
>  >>  distro and also transitively trust the signatures that we trust for
>  >>  our dependencies.
>  >>
>  >
>
>
> I actually meant to say include the pub key for the dependency in the
>  source distro.
>
>
>  > So effectively you are proposing a secondary indirect signature for
>  > each of those artefacts.
>  >
>  > But instead of signing the checksum list, why not generate signatures
>  > for the artefacts themselves and check those?
>  >
>
>
> But I like that idea too for the cases where it's  a 3rd party
>  dependency which does not sign it's artifacts or we don't trust it's
>  signatures (perhaps we don't think they go far enough to secure their
>  keys).
>
>
>  > You could then store the Apache sigs in the Maven repo, and they would
>  > then be available to all Apache projects - and to any others who
>  > decided to trust the Apache key.
>  >
>  >>  The end user would still need to manually validate the source distro 
> signature.
>  >>
>  >
>  > I can see that it would be an improvement over the existing Maven
>  > situation, but for me it does not go far enough.
>  >
>  > The problem is that the process of generating the checksum list does
>  > not scale well, and it forces every project to use fixed versions for
>  > each dependency.
>  >
>
>
> This should only be a problem while developing as official releases
>  should lock down the dependencies to known versions anyways.
>

As far as I know, many(most) releases depend on a minimum version, and
don't specify an upper version. How are you going to lock down
transitive dependencies, or are they not handled?

There's still the problem of scalability.

I think it might help your case if there was a fuller description of
the procedures that will need to be followed.

>
>  >>  Regards,
>  >>
>  >> Hiram
>  >>
>  >>
>  >>  On Sat, Sep 20, 2008 at 1:08 PM, Henning Schmiedehausen
>  >>  <[EMAIL PROTECTED]> wrote:
>  >>
>  >> > On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
>  >>  >> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
>  >>  >> <[EMAIL PROTECTED]> wrote:
>  >>  >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> 
> wrote:
>  >>  >> >> How about we include the signatures in the source distros?  That 
> way
>  >>  >> >> if you trust your source, then you can trust the dependencies it
>  >>  >> >> downloads.
>  >>  >> >
>  >>  >> > Eww.  That'd be a giant gaping security hole.
>  >>  >>
>  >>  >> not necessarily, depends how it's done
>  >>  >>
>  >>  >> signing works through trusting the people who own the keys. given
>  >>  >> sufficient signaturees (to prevent small conspiracies), where the
>  >>  >> signatures are downloaded from shouldn't matter.
>  >>  >
>  >>  > Hiram suggested to put the signatures into the source, which in turn is
>  >>  > also distributed from the repo. If you compromise the repo and change
>  >>  > the artifact, it is trivial to update the source artifact to contain a
>  >>  > matching signature.
>  >>  >
>  >>  > This is a security hole. And I don't really care for some of the
>  >>  > proposed "high nineties" security solutions. Either a solution is 
> secure
>  >>  > or it is not. Everything else is just FUD.
>  >>  >
>  >>  > The problem with the central repo is that you need an easy accessible
>  >>  > web of trust if you want validation. The Apache web of trust is
>  >>  > distributed and an overlay to the GPG web of trust. But if you live in
>  >>  > Juneau, Alaska, it is hard for you to access it and get a trust
>  >>  > relationship to it.
>  >>  >
>  >>  > There is a (bit rusty) proposal on how to improve this at
>  >>  > http://people.apache.org/~henkp/trust/
>  >>  >
>  >>  >Ciao
>  >>  >Henning
>  >>  >
>  >>  >
>  >>  >
>  >>  > -
>  >>  > 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-

Re: status of PGP support in Maven

[Henning Schmiedehausen]

On Sat, 2008-09-20 at 19:52 +0200, Jukka Zitting wrote:
> HI,
> 
> On Sat, Sep 20, 2008 at 7:08 PM, Henning Schmiedehausen
> <[EMAIL PROTECTED]> wrote:
> > Hiram suggested to put the signatures into the source, which in turn is
> > also distributed from the repo.
> 
> It's not. The sources you build come either from svn or from a signed
> release package.

What is a signed release package? If I can compromise the repository and
change signatures on an artifact, I can also change the signatures and
contents on a "signed release package". That does not work.

In <[EMAIL PROTECTED]>:

Hiram> How about we include the signatures in the source distros?  That
Hiram> way if you trust your source, then you can trust the dependencies
Hiram> it downloads.

Sounds pretty clear to me. Your suggestion again requires that the
verifier goes back to a central, trusted repository (Single point of
failure) and even more, it requires some sort of convention on where and
how to store these signatures. Does not scale.

Folks, if distributed trust was easy, Trust Centers wouldn't make a
fortune selling signed keys from a central trust source ("Root
certificate").

Ciao
Henning




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

On Mon, Sep 22, 2008 at 10:12 AM, sebb <[EMAIL PROTECTED]> wrote:
> On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> The only reason I suggested including the sigs in the source distro is
>>  because a source build like Apache ServiceMix depends on hundreds of
>>  third party dependencies.. so an end user would need to end up
>>  trusting LOTs different signatures to get ServiceMix to build.
>>
>>  It would be easier if the end user could just trust the Apache source
>>  distro and also transitively trust the signatures that we trust for
>>  our dependencies.
>>
>

I actually meant to say include the pub key for the dependency in the
source distro.

> So effectively you are proposing a secondary indirect signature for
> each of those artefacts.
>
> But instead of signing the checksum list, why not generate signatures
> for the artefacts themselves and check those?
>

But I like that idea too for the cases where it's  a 3rd party
dependency which does not sign it's artifacts or we don't trust it's
signatures (perhaps we don't think they go far enough to secure their
keys).

> You could then store the Apache sigs in the Maven repo, and they would
> then be available to all Apache projects - and to any others who
> decided to trust the Apache key.
>
>>  The end user would still need to manually validate the source distro 
>> signature.
>>
>
> I can see that it would be an improvement over the existing Maven
> situation, but for me it does not go far enough.
>
> The problem is that the process of generating the checksum list does
> not scale well, and it forces every project to use fixed versions for
> each dependency.
>

This should only be a problem while developing as official releases
should lock down the dependencies to known versions anyways.

>>  Regards,
>>
>> Hiram
>>
>>
>>  On Sat, Sep 20, 2008 at 1:08 PM, Henning Schmiedehausen
>>  <[EMAIL PROTECTED]> wrote:
>>
>> > On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
>>  >> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
>>  >> <[EMAIL PROTECTED]> wrote:
>>  >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> 
>> wrote:
>>  >> >> How about we include the signatures in the source distros?  That way
>>  >> >> if you trust your source, then you can trust the dependencies it
>>  >> >> downloads.
>>  >> >
>>  >> > Eww.  That'd be a giant gaping security hole.
>>  >>
>>  >> not necessarily, depends how it's done
>>  >>
>>  >> signing works through trusting the people who own the keys. given
>>  >> sufficient signaturees (to prevent small conspiracies), where the
>>  >> signatures are downloaded from shouldn't matter.
>>  >
>>  > Hiram suggested to put the signatures into the source, which in turn is
>>  > also distributed from the repo. If you compromise the repo and change
>>  > the artifact, it is trivial to update the source artifact to contain a
>>  > matching signature.
>>  >
>>  > This is a security hole. And I don't really care for some of the
>>  > proposed "high nineties" security solutions. Either a solution is secure
>>  > or it is not. Everything else is just FUD.
>>  >
>>  > The problem with the central repo is that you need an easy accessible
>>  > web of trust if you want validation. The Apache web of trust is
>>  > distributed and an overlay to the GPG web of trust. But if you live in
>>  > Juneau, Alaska, it is hard for you to access it and get a trust
>>  > relationship to it.
>>  >
>>  > There is a (bit rusty) proposal on how to improve this at
>>  > http://people.apache.org/~henkp/trust/
>>  >
>>  >Ciao
>>  >Henning
>>  >
>>  >
>>  >
>>  > -
>>  > 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]

Re: status of PGP support in Maven

[sebb]

On 22/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> The only reason I suggested including the sigs in the source distro is
>  because a source build like Apache ServiceMix depends on hundreds of
>  third party dependencies.. so an end user would need to end up
>  trusting LOTs different signatures to get ServiceMix to build.
>
>  It would be easier if the end user could just trust the Apache source
>  distro and also transitively trust the signatures that we trust for
>  our dependencies.
>

So effectively you are proposing a secondary indirect signature for
each of those artefacts.

But instead of signing the checksum list, why not generate signatures
for the artefacts themselves and check those?

You could then store the Apache sigs in the Maven repo, and they would
then be available to all Apache projects - and to any others who
decided to trust the Apache key.

>  The end user would still need to manually validate the source distro 
> signature.
>

I can see that it would be an improvement over the existing Maven
situation, but for me it does not go far enough.

The problem is that the process of generating the checksum list does
not scale well, and it forces every project to use fixed versions for
each dependency.

>  Regards,
>
> Hiram
>
>
>  On Sat, Sep 20, 2008 at 1:08 PM, Henning Schmiedehausen
>  <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
>  >> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
>  >> <[EMAIL PROTECTED]> wrote:
>  >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> 
> wrote:
>  >> >> How about we include the signatures in the source distros?  That way
>  >> >> if you trust your source, then you can trust the dependencies it
>  >> >> downloads.
>  >> >
>  >> > Eww.  That'd be a giant gaping security hole.
>  >>
>  >> not necessarily, depends how it's done
>  >>
>  >> signing works through trusting the people who own the keys. given
>  >> sufficient signaturees (to prevent small conspiracies), where the
>  >> signatures are downloaded from shouldn't matter.
>  >
>  > Hiram suggested to put the signatures into the source, which in turn is
>  > also distributed from the repo. If you compromise the repo and change
>  > the artifact, it is trivial to update the source artifact to contain a
>  > matching signature.
>  >
>  > This is a security hole. And I don't really care for some of the
>  > proposed "high nineties" security solutions. Either a solution is secure
>  > or it is not. Everything else is just FUD.
>  >
>  > The problem with the central repo is that you need an easy accessible
>  > web of trust if you want validation. The Apache web of trust is
>  > distributed and an overlay to the GPG web of trust. But if you live in
>  > Juneau, Alaska, it is hard for you to access it and get a trust
>  > relationship to it.
>  >
>  > There is a (bit rusty) proposal on how to improve this at
>  > http://people.apache.org/~henkp/trust/
>  >
>  >Ciao
>  >Henning
>  >
>  >
>  >
>  > -
>  > 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]

Re: status of PGP support in Maven

[James Carman]

Eclipse does something like this, doesn't it?  When you install a
plugin, it asks you to accept the license terms for all the stuff
that's being imported.  Couldn't maven do something similar?

On Mon, Sep 22, 2008 at 9:34 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> The only reason I suggested including the sigs in the source distro is
> because a source build like Apache ServiceMix depends on hundreds of
> third party dependencies.. so an end user would need to end up
> trusting LOTs different signatures to get ServiceMix to build.
>
> It would be easier if the end user could just trust the Apache source
> distro and also transitively trust the signatures that we trust for
> our dependencies.
>
> The end user would still need to manually validate the source distro 
> signature.
>
> Regards,
> Hiram
>
> On Sat, Sep 20, 2008 at 1:08 PM, Henning Schmiedehausen
> <[EMAIL PROTECTED]> wrote:
>> On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
>>> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
>>> <[EMAIL PROTECTED]> wrote:
>>> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>>> >> How about we include the signatures in the source distros?  That way
>>> >> if you trust your source, then you can trust the dependencies it
>>> >> downloads.
>>> >
>>> > Eww.  That'd be a giant gaping security hole.
>>>
>>> not necessarily, depends how it's done
>>>
>>> signing works through trusting the people who own the keys. given
>>> sufficient signaturees (to prevent small conspiracies), where the
>>> signatures are downloaded from shouldn't matter.
>>
>> Hiram suggested to put the signatures into the source, which in turn is
>> also distributed from the repo. If you compromise the repo and change
>> the artifact, it is trivial to update the source artifact to contain a
>> matching signature.
>>
>> This is a security hole. And I don't really care for some of the
>> proposed "high nineties" security solutions. Either a solution is secure
>> or it is not. Everything else is just FUD.
>>
>> The problem with the central repo is that you need an easy accessible
>> web of trust if you want validation. The Apache web of trust is
>> distributed and an overlay to the GPG web of trust. But if you live in
>> Juneau, Alaska, it is hard for you to access it and get a trust
>> relationship to it.
>>
>> There is a (bit rusty) proposal on how to improve this at
>> http://people.apache.org/~henkp/trust/
>>
>>Ciao
>>Henning
>>
>>
>>
>> -
>> 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]

Re: status of PGP support in Maven

[Hiram Chirino]

The only reason I suggested including the sigs in the source distro is
because a source build like Apache ServiceMix depends on hundreds of
third party dependencies.. so an end user would need to end up
trusting LOTs different signatures to get ServiceMix to build.

It would be easier if the end user could just trust the Apache source
distro and also transitively trust the signatures that we trust for
our dependencies.

The end user would still need to manually validate the source distro signature.

Regards,
Hiram

On Sat, Sep 20, 2008 at 1:08 PM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
>> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
>> <[EMAIL PROTECTED]> wrote:
>> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> >> How about we include the signatures in the source distros?  That way
>> >> if you trust your source, then you can trust the dependencies it
>> >> downloads.
>> >
>> > Eww.  That'd be a giant gaping security hole.
>>
>> not necessarily, depends how it's done
>>
>> signing works through trusting the people who own the keys. given
>> sufficient signaturees (to prevent small conspiracies), where the
>> signatures are downloaded from shouldn't matter.
>
> Hiram suggested to put the signatures into the source, which in turn is
> also distributed from the repo. If you compromise the repo and change
> the artifact, it is trivial to update the source artifact to contain a
> matching signature.
>
> This is a security hole. And I don't really care for some of the
> proposed "high nineties" security solutions. Either a solution is secure
> or it is not. Everything else is just FUD.
>
> The problem with the central repo is that you need an easy accessible
> web of trust if you want validation. The Apache web of trust is
> distributed and an overlay to the GPG web of trust. But if you live in
> Juneau, Alaska, it is hard for you to access it and get a trust
> relationship to it.
>
> There is a (bit rusty) proposal on how to improve this at
> http://people.apache.org/~henkp/trust/
>
>Ciao
>Henning
>
>
>
> -
> 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]

Re: status of PGP support in Maven

[Jukka Zitting]

HI,

On Sat, Sep 20, 2008 at 7:08 PM, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> Hiram suggested to put the signatures into the source, which in turn is
> also distributed from the repo.

It's not. The sources you build come either from svn or from a signed
release package.

BR,

Jukka Zitting

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Henning Schmiedehausen]

On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
> <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> >> How about we include the signatures in the source distros?  That way
> >> if you trust your source, then you can trust the dependencies it
> >> downloads.
> >
> > Eww.  That'd be a giant gaping security hole.
> 
> not necessarily, depends how it's done
> 
> signing works through trusting the people who own the keys. given
> sufficient signaturees (to prevent small conspiracies), where the
> signatures are downloaded from shouldn't matter.

Hiram suggested to put the signatures into the source, which in turn is
also distributed from the repo. If you compromise the repo and change
the artifact, it is trivial to update the source artifact to contain a
matching signature.

This is a security hole. And I don't really care for some of the
proposed "high nineties" security solutions. Either a solution is secure
or it is not. Everything else is just FUD.

The problem with the central repo is that you need an easy accessible
web of trust if you want validation. The Apache web of trust is
distributed and an overlay to the GPG web of trust. But if you live in
Juneau, Alaska, it is hard for you to access it and get a trust
relationship to it. 

There is a (bit rusty) proposal on how to improve this at
http://people.apache.org/~henkp/trust/

Ciao
Henning



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Robert Burrell Donkin]

On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
> On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> How about we include the signatures in the source distros?  That way
>> if you trust your source, then you can trust the dependencies it
>> downloads.
>
> Eww.  That'd be a giant gaping security hole.

not necessarily, depends how it's done

signing works through trusting the people who own the keys. given
sufficient signaturees (to prevent small conspiracies), where the
signatures are downloaded from shouldn't matter.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Justin Erenkrantz]

On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> How about we include the signatures in the source distros?  That way
> if you trust your source, then you can trust the dependencies it
> downloads.

Eww.  That'd be a giant gaping security hole.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

How about we include the signatures in the source distros?  That way
if you trust your source, then you can trust the dependencies it
downloads.

On Thu, Sep 18, 2008 at 12:22 PM, Craig L Russell <[EMAIL PROTECTED]> wrote:
>
> On Sep 17, 2008, at 5:32 PM, Henning Schmiedehausen wrote:
>
>> The only way around that I can see right away in a heavily mirrored
>> system, is to pull the signatures (and probably even the checksums) from
>> central all the time. Which represents a single point of failure and a
>> non-scaling element.
>>
> I do understand the single point of failure, which means that if Apache
> central happens to be down, users cannot get to the signatures.
>
> But I don't see the scaling problem. I understand that to download an
> artifact that's more than 200 bytes, you really need mirrors to relieve the
> burden on Apache central. But I'd guess that our central server could handle
> a few hundred (thousand?) xxx.asc file downloads per minute, far in excess
> of the load.
>
> To me, the only place to store .asc files for all artifacts is in central.
> Not maven central, and not mirrors.
>
> Craig
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
>



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

Re: status of PGP support in Maven

[Craig L Russell]

On Sep 17, 2008, at 5:32 PM, Henning Schmiedehausen wrote:


The only way around that I can see right away in a heavily mirrored
system, is to pull the signatures (and probably even the checksums)  
from

central all the time. Which represents a single point of failure and a
non-scaling element.

I do understand the single point of failure, which means that if  
Apache central happens to be down, users cannot get to the signatures.


But I don't see the scaling problem. I understand that to download an  
artifact that's more than 200 bytes, you really need mirrors to  
relieve the burden on Apache central. But I'd guess that our central  
server could handle a few hundred (thousand?) xxx.asc file downloads  
per minute, far in excess of the load.


To me, the only place to store .asc files for all artifacts is in  
central. Not maven central, and not mirrors.


Craig

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: status of PGP support in Maven

[William A. Rowe, Jr.]

Gilles Scokart wrote:

2008/9/15 William A. Rowe, Jr. <[EMAIL PROTECTED]>:

Brett Porter wrote:

For the releases to be identified as from the incubator, they'll need to
be
signed solely by "the incubator". Did you want to elaborate on how you
anticipated that set up working?

With PGP it's a web of trust.  Any ASF-role key would never be used to sign
any artifact.  Ideally, ASF-key would sign incubator key, incubator key
would sign Jane's key, Jane would RM and sign with her own key, and the web
of trust satisfies the trust requirement.


That would requires a complete isolated web of trust for the incubator
release.  If the incubating web of trust is trusted by someone that I
trust, then I would trust the incubating artefact without realising
that this artefact comes from the incubator.
I thought the objectif was to force the user to agree that he
understandd he is using an incubating artefact.


That's not the point of a signature.  Signature verification is a mechanism
to validate the origin of the package.  Not it's integrity vs. a checksum,
but that the package (and checksum) had not been altered in the repository
at the origin server, during transit (e.g. a man-in-the-middle attack) nor
locally.

If you (as an author) are satisfied that any 1.x.x release will satisfy
your dependency on package foo, even if you generate checksums on all
of 1.0.0 through current rev 1.1.12, that doesn't help you when foo then
ships package 1.2.0, effectively rendering maven worthless.

Signatures exist for a reason, they don't require pre-knowledge of some
package that does not yet exist, and serve to authenticate the packages
origin.  That's why .rpm and other distribution models all rely on them.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Gilles Scokart]

2008/9/15 William A. Rowe, Jr. <[EMAIL PROTECTED]>:
> Brett Porter wrote:
>>
>> For the releases to be identified as from the incubator, they'll need to
>> be
>> signed solely by "the incubator". Did you want to elaborate on how you
>> anticipated that set up working?
>
> With PGP it's a web of trust.  Any ASF-role key would never be used to sign
> any artifact.  Ideally, ASF-key would sign incubator key, incubator key
> would sign Jane's key, Jane would RM and sign with her own key, and the web
> of trust satisfies the trust requirement.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

That would requires a complete isolated web of trust for the incubator
release.  If the incubating web of trust is trusted by someone that I
trust, then I would trust the incubating artefact without realising
that this artefact comes from the incubator.
I thought the objectif was to force the user to agree that he
understandd he is using an incubating artefact.

I have the impression that I missunderstand something here.  But what?

-- 
Gilles Scokart

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Henning Schmiedehausen]

On Tue, 2008-09-16 at 01:02 +1100, Brett Porter wrote:

[...]
> Currently, it has checking turned on by default, but that isn't going to be
> a reasonable setting for some releases to come until the signatures in the
> repository are cleaned up. At the moment I've populated unsigned artifacts
> with a signature from a dummy key for testing purposes only.

Nice.

> 
> For the releases to be identified as from the incubator, they'll need to be
> signed solely by "the incubator". Did you want to elaborate on how you
> anticipated that set up working?

That sounds like a limitation of our signing model. Another scenario: I
have hacked a maven repository and put up a modified version of an
artifact. I can trivially find out, which Apache person signed that
release (by looking at the official site), then create a GPG key for
that person and sign that modified artifact.

Now someone tries to download the artifact. Checksums work out (because
I modified them, too), they pull the .asc file with the signature and it
shows "Artifact has been signed by @apache.org. This
key is not certified with a trusted signature.There is no indication
that the signature belongs to the owner. Do you want to continue (Y/N)?"

Now,

- how many downloaders in a hurry will press "Y"?
- how many will actually take the fingerprint and go to the master site
of that artifact and verify it?
- how many will press "N"? Especially when my hacked artifact is just a
dependency of a dependency for a tool that they want to check out?

The only way around that I can see right away in a heavily mirrored
system, is to pull the signatures (and probably even the checksums) from
central all the time. Which represents a single point of failure and a
non-scaling element. 

Our web of trust has the following weaknesses:

- both incubating and non-incubating releases can be signed by the same
person with the same key
- there is no requirement that a release manager's key is actually well
connected (or even somehow connected) to the web of trust. Same goes for
the downloaders subset of keys that they trust.
- there is no easy way for a downloader to get a "basic set of
signatures to trust"

Of course you could simply throw the release signatures away, add
"signed by central" signatures for all artifacts in the repo and have
that public key distributed. That is probably the easiest and best
scaling thing.

Best regards
Henning




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Hiram Chirino]

Something else that needs to be considered is what happens if
someone's private key in the web of trust gets compromised?
Once compromised. malicious releases could get re-rolled, and deployed.

I think GPG would be good to validate an initial dependency/checksum
for an artifact, but after that future builds should validate against
the artifact checksum.

Regards,
Hiram

On Mon, Sep 15, 2008 at 2:00 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Mon, Sep 15, 2008 at 3:40 PM, William A. Rowe, Jr.
> <[EMAIL PROTECTED]> wrote:
>> Brett Porter wrote:
>>>
>>> For the releases to be identified as from the incubator, they'll need to
>>> be
>>> signed solely by "the incubator". Did you want to elaborate on how you
>>> anticipated that set up working?
>>
>> With PGP it's a web of trust.  Any ASF-role key would never be used to sign
>> any artifact.  Ideally, ASF-key would sign incubator key, incubator key
>> would sign Jane's key, Jane would RM and sign with her own key, and the web
>> of trust satisfies the trust requirement.
>
> i think that this approach would require a shadow web for incubator keys
>
> suppose:
>
> alice is an apache committer
> alice has key K which is commented "APACHE CODE SIGNING KEY"
> alice is elected release manager for incubator podling P
> alice would need to create a new key S which is commented "INCUBATOR
> RELEASES ONLY"
> alice adds S to an incubator KEYS document
>
> then alice should ensure that S (not K) is the only key used to sign
> the release for P
>
> - robert
>
> -
> 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]