You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Brett Porter <br...@gmail.com> on 2008/09/15 16:02:51 UTC
Re: status of PGP support in Maven
I'll make an attempt not to derail the vote (probably futile!) by changing
the subject :)
2008/9/16 Noel J. Bergman <no...@devtech.com>
> For the moment, I am voting -1 on this proposal.
>
> Even though I understand both the desire and the fact that Maven's flaws
> make current the approaches to require that the user knowingly accept
> Incubator artifacts easy to work around, I am more in alignment with
> Craig's
> comments.
>
> Has their been any movement in the Maven project to address its failings?
I've already finished a working prototype based on the proposal that sat out
for some time. I need to backport it to the current release branch after the
first milestone is done. If you want to try a test build let me know.
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.
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?
Thanks,
Brett
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
Re: status of PGP support in Maven
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Sep 15, 2008 at 7:39 PM, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
>
> On Sep 15, 2008, at 4:40 PM, William A. Rowe, Jr. 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.
>
> Though in general I'd be a bit more inclined towards a derivative of our PGP
> network into x509 land - and then a solid hierarchy through the PMC's from
> there (e.g. pgp signed +1's can be swapped for a x509 signature - but with
> the 'recall once it has left the ranch which CRL';s give you).
x509 is nasty but something similar can be achieved by signing meta-data
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Sep 15, 2008, at 4:40 PM, William A. Rowe, Jr. 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.
Though in general I'd be a bit more inclined towards a derivative of
our PGP network into x509 land - and then a solid hierarchy through
the PMC's from there (e.g. pgp signed +1's can be swapped for a x509
signature - but with the 'recall once it has left the ranch which
CRL';s give you).
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Gilles Scokart wrote:
> 2008/9/15 William A. Rowe, Jr. <wr...@rowe-clan.net>:
>> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Gilles Scokart <gs...@gmail.com>.
2008/9/15 William A. Rowe, Jr. <wr...@rowe-clan.net>:
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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
<ro...@gmail.com> wrote:
> On Mon, Sep 15, 2008 at 3:40 PM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Sep 15, 2008 at 3:40 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by sebb <se...@gmail.com>.
On 21/09/2008, Henning Schmiedehausen <he...@schmiedehausen.org> 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
> > <he...@apache.org> 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 <af...@mail.gmail.com>:
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Sat, 2008-09-20 at 19:52 +0200, Jukka Zitting wrote:
> HI,
>
> On Sat, Sep 20, 2008 at 7:08 PM, Henning Schmiedehausen
> <he...@apache.org> 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 <af...@mail.gmail.com>:
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Jukka Zitting <ju...@gmail.com>.
HI,
On Sat, Sep 20, 2008 at 7:08 PM, Henning Schmiedehausen
<he...@apache.org> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Sep 24, 2008 at 2:02 PM, Henning Schmiedehausen
<he...@apache.org>wrote:
> There is a pretty nice proposal on
> http://people.apache.org/~henkp/trust/<http://people.apache.org/%7Ehenkp/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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <ni...@protocol7.com> wrote:
> On Tue, Oct 7, 2008 at 3:21 PM, Hiram Chirino <hi...@hiramchirino.com> 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:
> <dependency>
> <groupId>commons-lang</groupId>
> <artifactId>commons-lang</artifactId>
> <version>2.3</version>
> <hash>ABC...123</hash>
> </dependency>
>
> /niklas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niklas Gustavsson wrote:
> Is the idea to do this in the POM or similar? Having something like:
Can we please move this discussion to repository@apache.org or
infrastructure-dev@apache.org?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Oct 7, 2008 at 3:21 PM, Hiram Chirino <hi...@hiramchirino.com> 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:
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.3</version>
<hash>ABC...123</hash>
</dependency>
/niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Mon, Oct 6, 2008 at 11:39 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Mon, Oct 6, 2008 at 10:08 PM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Mon, Oct 6, 2008 at 10:08 PM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Oct 6, 2008 at 10:08 PM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Fri, Oct 3, 2008 at 8:01 PM, Henning Schmiedehausen
<he...@apache.org> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@apache.org>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@apache.org>.
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
> <he...@apache.org>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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Sep 24, 2008 at 1:20 PM, Henning Schmiedehausen
<he...@apache.org>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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Wed, Sep 24, 2008 at 1:20 AM, Henning Schmiedehausen
<he...@apache.org> 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 "dev@apache.org (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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@apache.org>.
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 "dev@apache.org (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 "dev@apache.org (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 "dev@apache.org (Code Signing Key)" with the same fingerprint.
Which one do you trust? [1]
a) When asking "dev@apache.org", 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 "dev@apache.org", 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by David Crossley <cr...@apache.org>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Key signing practicalities Was: status of PGP support in Maven
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Sep 24, 2008 at 8:36 AM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
> Any people near Helsinki, Finland who are willing to have a coffee and sign
> my key? ;-)
I'll be in Helsinki for two weeks after the ApacheCon US.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Key signing practicalities Was: status of PGP support in Maven
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Sep 24, 2008 at 2:36 PM, Janne Jalkanen <Ja...@ecyrd.com>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)?
>>
>
> Which reminds me - if one does not attend an Apache key signing event
> (which tend to be in faraway countries, traveling to which usually means
> parting with lots of cash), how *does* one get the key signed? Is there a
> regional list somewhere?
>
> Any people near Helsinki, Finland who are willing to have a coffee and sign
> my key? ;-)
Yes, asking for people on community@ in your "not faraway country" is one
way to do it. Another is that I am sure you travel once in a while, and
before going there, you can ask if someone is up for a coffee and
keysigning.
Cheers
Niclas
Re: Key signing practicalities Was: status of PGP support in Maven
Posted by David Crossley <cr...@apache.org>.
Janne Jalkanen 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)?
>
> Which reminds me - if one does not attend an Apache key signing event
> (which tend to be in faraway countries, traveling to which usually
> means parting with lots of cash), how *does* one get the key signed?
> Is there a regional list somewhere?
Not all committers have added themselves to people.apache.org ...
ASF Committer Map
http://people.apache.org/map.html
See other notes about key signing so that you are ready
when you do meet someone ...
https://svn.apache.org/repos/private/committers/docs/pgp-key-signing.txt
-David
> Any people near Helsinki, Finland who are willing to have a coffee
> and sign my key? ;-)
>
> /Janne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Key signing practicalities Was: status of PGP support in Maven
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Janne,
I will be traveling to Helsinki within the next 6 months (probably).
If you're on tripit you can watch for my trip (in case I forget for
some reason to let you know).
Craig
On Sep 23, 2008, at 11:36 PM, Janne Jalkanen 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)?
>
> Which reminds me - if one does not attend an Apache key signing
> event (which tend to be in faraway countries, traveling to which
> usually means parting with lots of cash), how *does* one get the key
> signed? Is there a regional list somewhere?
>
> Any people near Helsinki, Finland who are willing to have a coffee
> and sign my key? ;-)
>
> /Janne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Key signing practicalities Was: status of PGP support in Maven
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> 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)?
Which reminds me - if one does not attend an Apache key signing event
(which tend to be in faraway countries, traveling to which usually
means parting with lots of cash), how *does* one get the key signed?
Is there a regional list somewhere?
Any people near Helsinki, Finland who are willing to have a coffee
and sign my key? ;-)
/Janne
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Paul Querna <ch...@force-elite.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@apache.org>.
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Sep 24, 2008, at 3:44 PM, Hiram Chirino wrote:
> On Wed, Sep 24, 2008 at 1:27 AM, Henning Schmiedehausen
> <he...@apache.org> wrote:
>> On Mon, 2008-09-22 at 13:42 -0400, Hiram Chirino wrote:
>>> On Mon, Sep 22, 2008 at 10:12 AM, sebb <se...@gmail.com> wrote:
>>>> On 22/09/2008, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Wed, Sep 24, 2008 at 1:27 AM, Henning Schmiedehausen
<he...@apache.org> wrote:
> On Mon, 2008-09-22 at 13:42 -0400, Hiram Chirino wrote:
>> On Mon, Sep 22, 2008 at 10:12 AM, sebb <se...@gmail.com> wrote:
>> > On 22/09/2008, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@apache.org>.
On Mon, 2008-09-22 at 13:42 -0400, Hiram Chirino wrote:
> On Mon, Sep 22, 2008 at 10:12 AM, sebb <se...@gmail.com> wrote:
> > On 22/09/2008, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by sebb <se...@gmail.com>.
On 22/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On Mon, Sep 22, 2008 at 10:12 AM, sebb <se...@gmail.com> wrote:
> > On 22/09/2008, Hiram Chirino <hi...@hiramchirino.com> 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
> >> <he...@apache.org> 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
> >> >> <ju...@erenkrantz.com> wrote:
> >> >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: general-help@incubator.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Hiram
> >>
> >> Blog: http://hiramchirino.com
> >>
> >> Open Source SOA
> >> http://open.iona.com
> >>
> >> ---------------------------------------------------------------------
> >>
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Mon, Sep 22, 2008 at 10:12 AM, sebb <se...@gmail.com> wrote:
> On 22/09/2008, Hiram Chirino <hi...@hiramchirino.com> 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
>> <he...@apache.org> 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
>> >> <ju...@erenkrantz.com> wrote:
>> >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by sebb <se...@gmail.com>.
On 22/09/2008, Hiram Chirino <hi...@hiramchirino.com> 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
> <he...@apache.org> 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
> >> <ju...@erenkrantz.com> wrote:
> >> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by James Carman <ja...@carmanconsulting.com>.
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 <hi...@hiramchirino.com> 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
> <he...@apache.org> 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
>>> <ju...@erenkrantz.com> wrote:
>>> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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
<he...@apache.org> 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
>> <ju...@erenkrantz.com> wrote:
>> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Sep 20, 2008 at 6:08 PM, Henning Schmiedehausen
<he...@apache.org> 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
>> <ju...@erenkrantz.com> wrote:
>> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@apache.org>.
On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote:
> On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
> <ju...@erenkrantz.com> wrote:
> > On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino <hi...@hiramchirino.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <Cr...@sun.com> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Craig L Russell <Cr...@Sun.COM>.
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new draft Incubator project proposal: Kato
Posted by Davanum Srinivas <da...@gmail.com>.
Steve,
Is there any interest in developing GUI/command-line tools that an
end-user can actually use as part of the project? Or is it just the
API+RI?
thanks,
dims
On Thu, Sep 18, 2008 at 5:01 AM, Steve Poole <SP...@uk.ibm.com> wrote:
> Greetings, I have just posted to the Incubator wiki a draft project
> proposal. http://wiki.apache.org/incubator/KatoProposal
>
> The proposal abstract states
>
> "Kato is a project to develop the Specification, Reference Implementation
> and Technology Compatibility Kit for JSR 326: Post-mortem JVM Diagnostics
> API "
>
> The proposal is not complete. It's missing a champion, mentors and a
> good review! I'd appreciate any comments, suggestions or volunteers
> from the community.
>
> Thanks
>
> Steve Poole
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: new draft Incubator project proposal: Kato
Posted by Steve Poole <SP...@uk.ibm.com>.
I've somehow managed to attach this note to another thread so I'll repost
the original as a top level email.
Steve Poole
Steve Poole/UK/IBM@IBMGB
18/09/2008 10:01
Please respond to
general@incubator.apache.org
To
general@incubator.apache.org
cc
Subject
new draft Incubator project proposal: Kato
Greetings, I have just posted to the Incubator wiki a draft project
proposal. http://wiki.apache.org/incubator/KatoProposal
The proposal abstract states
"Kato is a project to develop the Specification, Reference Implementation
and Technology Compatibility Kit for JSR 326: Post-mortem JVM Diagnostics
API "
The proposal is not complete. It's missing a champion, mentors and a
good review! I'd appreciate any comments, suggestions or volunteers
from the community.
Thanks
Steve Poole
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
new draft Incubator project proposal: Kato
Posted by Steve Poole <SP...@uk.ibm.com>.
Greetings, I have just posted to the Incubator wiki a draft project
proposal. http://wiki.apache.org/incubator/KatoProposal
The proposal abstract states
"Kato is a project to develop the Specification, Reference Implementation
and Technology Compatibility Kit for JSR 326: Post-mortem JVM Diagnostics
API "
The proposal is not complete. It's missing a champion, mentors and a
good review! I'd appreciate any comments, suggestions or volunteers
from the community.
Thanks
Steve Poole
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
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 <release manager>@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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org