You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2008/07/11 18:42:50 UTC
artifact signing feature branches
Hi,
I've wanted to pick up my work on this for some time and was prodded
by the general@incubator threads to take another crack at this.
http://docs.codehaus.org/display/MAVEN/Repository+Security (the issue
and related branches are linked)
I've created a couple of branches to try integrating the work again in
as simple and non-intrusive manner (both in code and to the user) as
possible. I already have commons-openpgp in the sandbox from some time
ago to deal with processing the signatures (it doesn't have any
external dependencies other than bouncy castle), so I'll integrate that.
If anyone else wants to offer feedback or dive in, you're more than
welcome!
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Brett Porter <br...@apache.org>.
On 12/07/2008, at 3:11 AM, David Jencks wrote:
>
> On Jul 11, 2008, at 9:42 AM, Brett Porter wrote:
>
>> Hi,
>>
>> I've wanted to pick up my work on this for some time and was
>> prodded by the general@incubator threads to take another crack at
>> this.
>>
>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>> issue and related branches are linked)
> <nit-pick>
> Are the sample settings in the repo sig policy section backwards?
>
> <releases>
> <signaturePolicy>ignore</signaturePolicy> <!-- can be fail
> (default), warn or ignore -->
> </releases>
> <snapshots>
> <signaturePolicy>warn</signaturePolicy> <!-- can be fail, warn or
> ignore (default) -->
> </snapshots>
They're just random samples - the defaults are listed on the right. Do
those look right to you?
Thanks,
Brett
>
>
>
> </nit-pick>
>
> david jencks
>
>>
>>
>> I've created a couple of branches to try integrating the work again
>> in as simple and non-intrusive manner (both in code and to the
>> user) as possible. I already have commons-openpgp in the sandbox
>> from some time ago to deal with processing the signatures (it
>> doesn't have any external dependencies other than bouncy castle),
>> so I'll integrate that.
>>
>> If anyone else wants to offer feedback or dive in, you're more than
>> welcome!
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by David Jencks <da...@yahoo.com>.
On Jul 11, 2008, at 9:42 AM, Brett Porter wrote:
> Hi,
>
> I've wanted to pick up my work on this for some time and was prodded
> by the general@incubator threads to take another crack at this.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
> issue and related branches are linked)
<nit-pick>
Are the sample settings in the repo sig policy section backwards?
<releases>
<signaturePolicy>ignore</signaturePolicy> <!-- can be fail
(default), warn or ignore -->
</releases>
<snapshots>
<signaturePolicy>warn</signaturePolicy> <!-- can be fail, warn or
ignore (default) -->
</snapshots>
</nit-pick>
david jencks
>
>
> I've created a couple of branches to try integrating the work again
> in as simple and non-intrusive manner (both in code and to the user)
> as possible. I already have commons-openpgp in the sandbox from some
> time ago to deal with processing the signatures (it doesn't have any
> external dependencies other than bouncy castle), so I'll integrate
> that.
>
> If anyone else wants to offer feedback or dive in, you're more than
> welcome!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/23/08, Jason van Zyl <ja...@maven.org> wrote:
>
> On 22-Jul-08, at 8:55 PM, Brett Porter wrote:
>
>>
>> On 23/07/2008, at 4:23 AM, Robert Burrell Donkin wrote:
>>
>>> On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <br...@apache.org>
>>> wrote:
>>>> Hi,
>>>>
>>>> I've wanted to pick up my work on this for some time and was
>>>> prodded by the
>>>> general@incubator threads to take another crack at this.
>>>>
>>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>>> issue and
>>>> related branches are linked)
>>>
>>> (sorry for picking this up late)
>>>
>>> in general, definitely worth implementing and a big improvement
>>>
>>> there are some weaknesses in a single set of trusted keys: it's a
>>> very
>>> coursely grained trust model. i may trust B1313DE2 to sign commons
>>> and
>>> JAMES releases but not maven ones. the owner of B1313DE2 may be
>>> expelled from apache.org but there is no way for an organisation to
>>> automatically inform the user that this key is not longer to be
>>> trusted for their releases. signed meta-data is one way to approach
>>> this problem.
>>
>> Right. I do have a section at the bottom where you can trust only
>> certain people for certain keys that you've picked up below, but it
>> was rightly pointed out that might be overkill.
>>
>> We do need a specific answer to your described story, and it also
>> applies in the other direction - you don't want to have to load
>> every Apache committers key to say you trust everything from Apache.
>> I haven't fully investigated the security implications of using role
>> keys to sign others.
>
> From my understanding using role keys is a good thing because you can
> partition use. If one partition is compromised you don't have to go
> invalidate everything you've ever signed.
+1
It should be possible to distribute trust meta-data at the
organization level partitioned by group ID. Users could download this
directly from the master site.
Robert
>
>>
>>
>>>
>>>
>>>> Per-artifact settings
>>>>
>>>> By default, all keys in the user's keyring will be accepted.
>>>> However, to strengthen a requirement,
>>>> a project may require that the key be a particular one, or signed
>>>> by a particular key. The key
>>>> provided might be either an email address or the key ID.
>>>
>>> identifier used:
>>> a. definitely shouldn't be the email address since this is trivial
>>> to fake
>>> b. collisions are possible between Key IDs and (given an ID) it may
>>> be possible to construct a colliding key though this would be
>>> definitely non-trivial
>>> c. recommended that the fingerprint is used (the Key ID is
>>> derivable from it)
>>
>> These are all intended to be a user convenience for specifying them,
>> and it's the users responsibility to get the right key into their
>> keyring for the given identifier.
>>
>> Certainly any mechanism that helps retrieve a key to add to the
>> keyring should be verifying the fingerprint.
>>
>> Do keyrings support adding multiple keys with the same ID but
>> different fingerprints? I didn't know that was an issue.
>>
>>>
>>>
>>>> Web of Trust
>>>>
>>>> Initially, the user will be required to explicitly add keys to
>>>> their keyring that they accept.
>>>
>>> this may need a little more thought. adding keys to the rings only
>>> allows a signature to be verified. only signed keys are trusted and
>>> this is a separate action. checking signatures is worthwhile even if
>>> the singature is untrusted: though a valid untrusted signature does
>>> not allow for positive validation, if the signature is invalid even
>>> when the signature is untrusted this indicates an attack of some
>>> kind.
>>>
>>> in general, i think that automatic download is very important for
>>> usability. in my experience, users often have problems understanding
>>> key servers.
>>
>> I agree this area needs more thought (and it's similar to your first
>> point).
>>
>> WoT won't be sufficient on it's own as most users have never had
>> contact with other signers. However it does need to be used for
>> automatically downloading keys (which does make it much easier to
>> use, for certain).
>>
>>>
>>>
>>>> The key should be downloaded from a trusted keyserver or KEYS file
>>>> (as specified in settings.xml above), not from the repository that
>>>> the artifact is being downloaded from.
>>>
>>> this may need more thought. these distribution mechanisms are
>>> typically intended to just distribute keys without gaurantees.
>>
>> I think getting KEYS (not automatically) from the original web
>> server should be satisfactory to most users in terms of
>> trustworthiness. It was poorly worded in that it looked like that
>> might be a transparent action where it's not though.
>>
>>>
>>>
>>> another weakness when not using keyservers is how revocation
>>> certificates can be distributed.
>>
>> This is true.
>>
>> Thanks for the feedback!
>>
>> Cheers,
>> Brett
>>
>>
>>>
>>>
>>> - robert
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more
> examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/23/08, Jason van Zyl <ja...@maven.org> wrote:
>
> On 22-Jul-08, at 8:55 PM, Brett Porter wrote:
>
>>
>> On 23/07/2008, at 4:23 AM, Robert Burrell Donkin wrote:
>>
>>> On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <br...@apache.org>
>>> wrote:
>>>> Hi,
>>>>
>>>> I've wanted to pick up my work on this for some time and was
>>>> prodded by the
>>>> general@incubator threads to take another crack at this.
>>>>
>>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>>> issue and
>>>> related branches are linked)
>>>
>>> (sorry for picking this up late)
>>>
>>> in general, definitely worth implementing and a big improvement
>>>
>>> there are some weaknesses in a single set of trusted keys: it's a
>>> very
>>> coursely grained trust model. i may trust B1313DE2 to sign commons
>>> and
>>> JAMES releases but not maven ones. the owner of B1313DE2 may be
>>> expelled from apache.org but there is no way for an organisation to
>>> automatically inform the user that this key is not longer to be
>>> trusted for their releases. signed meta-data is one way to approach
>>> this problem.
>>
>> Right. I do have a section at the bottom where you can trust only
>> certain people for certain keys that you've picked up below, but it
>> was rightly pointed out that might be overkill.
>>
>> We do need a specific answer to your described story, and it also
>> applies in the other direction - you don't want to have to load
>> every Apache committers key to say you trust everything from Apache.
>> I haven't fully investigated the security implications of using role
>> keys to sign others.
>
> From my understanding using role keys is a good thing because you can
> partition use. If one partition is compromised you don't have to go
> invalidate everything you've ever signed.
+1
It should be possible to distribute trust meta-data at the
organization level partitioned by group ID. Users could download this
directly from the master site.
Robert
>
>>
>>
>>>
>>>
>>>> Per-artifact settings
>>>>
>>>> By default, all keys in the user's keyring will be accepted.
>>>> However, to strengthen a requirement,
>>>> a project may require that the key be a particular one, or signed
>>>> by a particular key. The key
>>>> provided might be either an email address or the key ID.
>>>
>>> identifier used:
>>> a. definitely shouldn't be the email address since this is trivial
>>> to fake
>>> b. collisions are possible between Key IDs and (given an ID) it may
>>> be possible to construct a colliding key though this would be
>>> definitely non-trivial
>>> c. recommended that the fingerprint is used (the Key ID is
>>> derivable from it)
>>
>> These are all intended to be a user convenience for specifying them,
>> and it's the users responsibility to get the right key into their
>> keyring for the given identifier.
>>
>> Certainly any mechanism that helps retrieve a key to add to the
>> keyring should be verifying the fingerprint.
>>
>> Do keyrings support adding multiple keys with the same ID but
>> different fingerprints? I didn't know that was an issue.
>>
>>>
>>>
>>>> Web of Trust
>>>>
>>>> Initially, the user will be required to explicitly add keys to
>>>> their keyring that they accept.
>>>
>>> this may need a little more thought. adding keys to the rings only
>>> allows a signature to be verified. only signed keys are trusted and
>>> this is a separate action. checking signatures is worthwhile even if
>>> the singature is untrusted: though a valid untrusted signature does
>>> not allow for positive validation, if the signature is invalid even
>>> when the signature is untrusted this indicates an attack of some
>>> kind.
>>>
>>> in general, i think that automatic download is very important for
>>> usability. in my experience, users often have problems understanding
>>> key servers.
>>
>> I agree this area needs more thought (and it's similar to your first
>> point).
>>
>> WoT won't be sufficient on it's own as most users have never had
>> contact with other signers. However it does need to be used for
>> automatically downloading keys (which does make it much easier to
>> use, for certain).
>>
>>>
>>>
>>>> The key should be downloaded from a trusted keyserver or KEYS file
>>>> (as specified in settings.xml above), not from the repository that
>>>> the artifact is being downloaded from.
>>>
>>> this may need more thought. these distribution mechanisms are
>>> typically intended to just distribute keys without gaurantees.
>>
>> I think getting KEYS (not automatically) from the original web
>> server should be satisfactory to most users in terms of
>> trustworthiness. It was poorly worded in that it looked like that
>> might be a transparent action where it's not though.
>>
>>>
>>>
>>> another weakness when not using keyservers is how revocation
>>> certificates can be distributed.
>>
>> This is true.
>>
>> Thanks for the feedback!
>>
>> Cheers,
>> Brett
>>
>>
>>>
>>>
>>> - robert
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more
> examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Jason van Zyl <ja...@maven.org>.
On 22-Jul-08, at 8:55 PM, Brett Porter wrote:
>
> On 23/07/2008, at 4:23 AM, Robert Burrell Donkin wrote:
>
>> On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <br...@apache.org>
>> wrote:
>>> Hi,
>>>
>>> I've wanted to pick up my work on this for some time and was
>>> prodded by the
>>> general@incubator threads to take another crack at this.
>>>
>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>> issue and
>>> related branches are linked)
>>
>> (sorry for picking this up late)
>>
>> in general, definitely worth implementing and a big improvement
>>
>> there are some weaknesses in a single set of trusted keys: it's a
>> very
>> coursely grained trust model. i may trust B1313DE2 to sign commons
>> and
>> JAMES releases but not maven ones. the owner of B1313DE2 may be
>> expelled from apache.org but there is no way for an organisation to
>> automatically inform the user that this key is not longer to be
>> trusted for their releases. signed meta-data is one way to approach
>> this problem.
>
> Right. I do have a section at the bottom where you can trust only
> certain people for certain keys that you've picked up below, but it
> was rightly pointed out that might be overkill.
>
> We do need a specific answer to your described story, and it also
> applies in the other direction - you don't want to have to load
> every Apache committers key to say you trust everything from Apache.
> I haven't fully investigated the security implications of using role
> keys to sign others.
From my understanding using role keys is a good thing because you can
partition use. If one partition is compromised you don't have to go
invalidate everything you've ever signed.
>
>
>>
>>
>>> Per-artifact settings
>>>
>>> By default, all keys in the user's keyring will be accepted.
>>> However, to strengthen a requirement,
>>> a project may require that the key be a particular one, or signed
>>> by a particular key. The key
>>> provided might be either an email address or the key ID.
>>
>> identifier used:
>> a. definitely shouldn't be the email address since this is trivial
>> to fake
>> b. collisions are possible between Key IDs and (given an ID) it may
>> be possible to construct a colliding key though this would be
>> definitely non-trivial
>> c. recommended that the fingerprint is used (the Key ID is
>> derivable from it)
>
> These are all intended to be a user convenience for specifying them,
> and it's the users responsibility to get the right key into their
> keyring for the given identifier.
>
> Certainly any mechanism that helps retrieve a key to add to the
> keyring should be verifying the fingerprint.
>
> Do keyrings support adding multiple keys with the same ID but
> different fingerprints? I didn't know that was an issue.
>
>>
>>
>>> Web of Trust
>>>
>>> Initially, the user will be required to explicitly add keys to
>>> their keyring that they accept.
>>
>> this may need a little more thought. adding keys to the rings only
>> allows a signature to be verified. only signed keys are trusted and
>> this is a separate action. checking signatures is worthwhile even if
>> the singature is untrusted: though a valid untrusted signature does
>> not allow for positive validation, if the signature is invalid even
>> when the signature is untrusted this indicates an attack of some
>> kind.
>>
>> in general, i think that automatic download is very important for
>> usability. in my experience, users often have problems understanding
>> key servers.
>
> I agree this area needs more thought (and it's similar to your first
> point).
>
> WoT won't be sufficient on it's own as most users have never had
> contact with other signers. However it does need to be used for
> automatically downloading keys (which does make it much easier to
> use, for certain).
>
>>
>>
>>> The key should be downloaded from a trusted keyserver or KEYS file
>>> (as specified in settings.xml above), not from the repository that
>>> the artifact is being downloaded from.
>>
>> this may need more thought. these distribution mechanisms are
>> typically intended to just distribute keys without gaurantees.
>
> I think getting KEYS (not automatically) from the original web
> server should be satisfactory to most users in terms of
> trustworthiness. It was poorly worded in that it looked like that
> might be a transparent action where it's not though.
>
>>
>>
>> another weakness when not using keyservers is how revocation
>> certificates can be distributed.
>
> This is true.
>
> Thanks for the feedback!
>
> Cheers,
> Brett
>
>
>>
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Chad La Joie <ch...@switch.ch>.
I personally wouldn't feel comfortable with Maven auto-fetching keys,
unless it's working in a web-of-trust mode. How would I verify that the
keys were any good otherwise? It's pretty likely that any compromise
that allowed some one to place a rogue artifact could also add their key
in to the master key file on the webserver.
Instead I would expect Maven to ship with a keyring that had a couple
keys in it, corresponding to maven developers. When I wanted to pull in
new components signed by different keys I'd have to add those keys
manually after I had verified the key.
Robert Burrell Donkin wrote:
>>>> The key should be downloaded from a trusted keyserver or KEYS file
>>>> (as specified in settings.xml above), not from the repository that
>>>> the artifact is being downloaded from.
>>> this may need more thought. these distribution mechanisms are
>>> typically intended to just distribute keys without gaurantees.
>> I think getting KEYS (not automatically) from the original web server
>> should be satisfactory to most users in terms of trustworthiness. It
>> was poorly worded in that it looked like that might be a transparent
>> action where it's not though.
>
> I would only trust KEYS for a particular purpose, not generally
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad.lajoie@switch.ch, http://www.switch.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/23/08, Brett Porter <br...@apache.org> wrote:
>
> On 23/07/2008, at 4:23 AM, Robert Burrell Donkin wrote:
>
>> On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <br...@apache.org>
>> wrote:
>>> Hi,
>>>
>>> I've wanted to pick up my work on this for some time and was
>>> prodded by the
>>> general@incubator threads to take another crack at this.
>>>
>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>> issue and
>>> related branches are linked)
>>
>> (sorry for picking this up late)
>>
>> in general, definitely worth implementing and a big improvement
>>
>> there are some weaknesses in a single set of trusted keys: it's a very
>> coursely grained trust model. i may trust B1313DE2 to sign commons and
>> JAMES releases but not maven ones. the owner of B1313DE2 may be
>> expelled from apache.org but there is no way for an organisation to
>> automatically inform the user that this key is not longer to be
>> trusted for their releases. signed meta-data is one way to approach
>> this problem.
>
> Right. I do have a section at the bottom where you can trust only
> certain people for certain keys that you've picked up below, but it
> was rightly pointed out that might be overkill.
>
> We do need a specific answer to your described story, and it also
> applies in the other direction - you don't want to have to load every
> Apache committers key to say you trust everything from Apache. I
> haven't fully investigated the security implications of using role
> keys to sign others.
>
>>
>>
>>> Per-artifact settings
>>>
>>> By default, all keys in the user's keyring will be accepted.
>>> However, to strengthen a requirement,
>>> a project may require that the key be a particular one, or signed
>>> by a particular key. The key
>>> provided might be either an email address or the key ID.
>>
>> identifier used:
>> a. definitely shouldn't be the email address since this is trivial
>> to fake
>> b. collisions are possible between Key IDs and (given an ID) it may
>> be possible to construct a colliding key though this would be
>> definitely non-trivial
>> c. recommended that the fingerprint is used (the Key ID is derivable
>> from it)
>
> These are all intended to be a user convenience for specifying them,
> and it's the users responsibility to get the right key into their
> keyring for the given identifier.
>
> Certainly any mechanism that helps retrieve a key to add to the
> keyring should be verifying the fingerprint.
>
> Do keyrings support adding multiple keys with the same ID but
> different fingerprints? I didn't know that was an issue.
Unintentionally generated two keys with the same ID is very unlikely.
So I'm not sure what would happen if two were added to a client.
However, intentionally generating a key with the same ID is a possible
attack vector. AIUI the fingerprint is strong enough for this attack
to be unfeasible and the fingerprint needs to be checked.
>
>>
>>
>>> Web of Trust
>>>
>>> Initially, the user will be required to explicitly add keys to
>>> their keyring that they accept.
>>
>> this may need a little more thought. adding keys to the rings only
>> allows a signature to be verified. only signed keys are trusted and
>> this is a separate action. checking signatures is worthwhile even if
>> the singature is untrusted: though a valid untrusted signature does
>> not allow for positive validation, if the signature is invalid even
>> when the signature is untrusted this indicates an attack of some kind.
>>
>> in general, i think that automatic download is very important for
>> usability. in my experience, users often have problems understanding
>> key servers.
>
> I agree this area needs more thought (and it's similar to your first
> point).
>
> WoT won't be sufficient on it's own as most users have never had
> contact with other signers. However it does need to be used for
> automatically downloading keys (which does make it much easier to use,
> for certain).
>
>>
>>
>>> The key should be downloaded from a trusted keyserver or KEYS file
>>> (as specified in settings.xml above), not from the repository that
>>> the artifact is being downloaded from.
>>
>> this may need more thought. these distribution mechanisms are
>> typically intended to just distribute keys without gaurantees.
>
> I think getting KEYS (not automatically) from the original web server
> should be satisfactory to most users in terms of trustworthiness. It
> was poorly worded in that it looked like that might be a transparent
> action where it's not though.
I would only trust KEYS for a particular purpose, not generally
Robert
>
>>
>>
>> another weakness when not using keyservers is how revocation
>> certificates can be distributed.
>
> This is true.
>
> Thanks for the feedback!
>
> Cheers,
> Brett
>
>
>>
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Brett Porter <br...@apache.org>.
On 23/07/2008, at 4:23 AM, Robert Burrell Donkin wrote:
> On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <br...@apache.org>
> wrote:
>> Hi,
>>
>> I've wanted to pick up my work on this for some time and was
>> prodded by the
>> general@incubator threads to take another crack at this.
>>
>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>> issue and
>> related branches are linked)
>
> (sorry for picking this up late)
>
> in general, definitely worth implementing and a big improvement
>
> there are some weaknesses in a single set of trusted keys: it's a very
> coursely grained trust model. i may trust B1313DE2 to sign commons and
> JAMES releases but not maven ones. the owner of B1313DE2 may be
> expelled from apache.org but there is no way for an organisation to
> automatically inform the user that this key is not longer to be
> trusted for their releases. signed meta-data is one way to approach
> this problem.
Right. I do have a section at the bottom where you can trust only
certain people for certain keys that you've picked up below, but it
was rightly pointed out that might be overkill.
We do need a specific answer to your described story, and it also
applies in the other direction - you don't want to have to load every
Apache committers key to say you trust everything from Apache. I
haven't fully investigated the security implications of using role
keys to sign others.
>
>
>> Per-artifact settings
>>
>> By default, all keys in the user's keyring will be accepted.
>> However, to strengthen a requirement,
>> a project may require that the key be a particular one, or signed
>> by a particular key. The key
>> provided might be either an email address or the key ID.
>
> identifier used:
> a. definitely shouldn't be the email address since this is trivial
> to fake
> b. collisions are possible between Key IDs and (given an ID) it may
> be possible to construct a colliding key though this would be
> definitely non-trivial
> c. recommended that the fingerprint is used (the Key ID is derivable
> from it)
These are all intended to be a user convenience for specifying them,
and it's the users responsibility to get the right key into their
keyring for the given identifier.
Certainly any mechanism that helps retrieve a key to add to the
keyring should be verifying the fingerprint.
Do keyrings support adding multiple keys with the same ID but
different fingerprints? I didn't know that was an issue.
>
>
>> Web of Trust
>>
>> Initially, the user will be required to explicitly add keys to
>> their keyring that they accept.
>
> this may need a little more thought. adding keys to the rings only
> allows a signature to be verified. only signed keys are trusted and
> this is a separate action. checking signatures is worthwhile even if
> the singature is untrusted: though a valid untrusted signature does
> not allow for positive validation, if the signature is invalid even
> when the signature is untrusted this indicates an attack of some kind.
>
> in general, i think that automatic download is very important for
> usability. in my experience, users often have problems understanding
> key servers.
I agree this area needs more thought (and it's similar to your first
point).
WoT won't be sufficient on it's own as most users have never had
contact with other signers. However it does need to be used for
automatically downloading keys (which does make it much easier to use,
for certain).
>
>
>> The key should be downloaded from a trusted keyserver or KEYS file
>> (as specified in settings.xml above), not from the repository that
>> the artifact is being downloaded from.
>
> this may need more thought. these distribution mechanisms are
> typically intended to just distribute keys without gaurantees.
I think getting KEYS (not automatically) from the original web server
should be satisfactory to most users in terms of trustworthiness. It
was poorly worded in that it looked like that might be a transparent
action where it's not though.
>
>
> another weakness when not using keyservers is how revocation
> certificates can be distributed.
This is true.
Thanks for the feedback!
Cheers,
Brett
>
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> I've wanted to pick up my work on this for some time and was prodded by the
> general@incubator threads to take another crack at this.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security (the issue and
> related branches are linked)
(sorry for picking this up late)
in general, definitely worth implementing and a big improvement
there are some weaknesses in a single set of trusted keys: it's a very
coursely grained trust model. i may trust B1313DE2 to sign commons and
JAMES releases but not maven ones. the owner of B1313DE2 may be
expelled from apache.org but there is no way for an organisation to
automatically inform the user that this key is not longer to be
trusted for their releases. signed meta-data is one way to approach
this problem.
> Per-artifact settings
>
> By default, all keys in the user's keyring will be accepted. However, to strengthen a requirement,
> a project may require that the key be a particular one, or signed by a particular key. The key
> provided might be either an email address or the key ID.
identifier used:
a. definitely shouldn't be the email address since this is trivial to fake
b. collisions are possible between Key IDs and (given an ID) it may
be possible to construct a colliding key though this would be
definitely non-trivial
c. recommended that the fingerprint is used (the Key ID is derivable from it)
> Web of Trust
>
> Initially, the user will be required to explicitly add keys to their keyring that they accept.
this may need a little more thought. adding keys to the rings only
allows a signature to be verified. only signed keys are trusted and
this is a separate action. checking signatures is worthwhile even if
the singature is untrusted: though a valid untrusted signature does
not allow for positive validation, if the signature is invalid even
when the signature is untrusted this indicates an attack of some kind.
in general, i think that automatic download is very important for
usability. in my experience, users often have problems understanding
key servers.
> The key should be downloaded from a trusted keyserver or KEYS file (as specified in settings.xml above), not from the repository that the artifact is being downloaded from.
this may need more thought. these distribution mechanisms are
typically intended to just distribute keys without gaurantees.
another weakness when not using keyservers is how revocation
certificates can be distributed.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Brett Porter <br...@apache.org>.
I see where you were coming from with the lifecycle now.
Do you also need to veryify them as part of the build process, or only
out of the repository itself?
Cheers,
Brett
On 12/07/2008, at 8:28 AM, Christian Edward Gruber wrote:
> Nope. I'd have to check, but they're signatures which are then
> zipped up with the code.
>
> What I'm realizing is that this may actually be irrelevant, as their
> whole packaging ends up different than a typical jar, and they have
> index files and signatures against each .class file, and then the
> whole is also signed. It's very convoluted and what we've been
> doing in the mavenization effort is to un-jar (in a packaging
> project) into a folder, do the various signatures, then sign the
> collection, then zip it up, and that's the artifact from the
> packaging project, as opposed to the original.
>
> So never mind, they have an edge-case we're handling with post-
> processing the whole artifact into a new artifact. I can't solve
> their problem without a lot of convolution in one project, and the
> new signing stuff won't really be relevant. (They're constrained by
> an industry specification that includes this wierd signing protocol)
>
> Christian.
>
> On 11-Jul-08, at 13:59 , Brian E. Fox wrote:
>
>> Christian, what kind of files are produced with the sig? Are they
>> still
>> .asc?
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Christian Edward Gruber <ch...@gmail.com>.
Nope. I'd have to check, but they're signatures which are then zipped
up with the code.
What I'm realizing is that this may actually be irrelevant, as their
whole packaging ends up different than a typical jar, and they have
index files and signatures against each .class file, and then the
whole is also signed. It's very convoluted and what we've been doing
in the mavenization effort is to un-jar (in a packaging project) into
a folder, do the various signatures, then sign the collection, then
zip it up, and that's the artifact from the packaging project, as
opposed to the original.
So never mind, they have an edge-case we're handling with post-
processing the whole artifact into a new artifact. I can't solve
their problem without a lot of convolution in one project, and the new
signing stuff won't really be relevant. (They're constrained by an
industry specification that includes this wierd signing protocol)
Christian.
On 11-Jul-08, at 13:59 , Brian E. Fox wrote:
> Christian, what kind of files are produced with the sig? Are they
> still
> .asc?
>
> -----Original Message-----
> From: Christian Edward Gruber [mailto:christianedwardgruber@gmail.com]
> Sent: Friday, July 11, 2008 1:24 PM
> To: Maven Developers List
> Subject: Re: artifact signing feature branches
>
> Incidentally, I presume that there is a provider for PGP that could be
> replaced by an alternate signing system if a provider were written for
> it? I didn't see it in the wiki, but I have a client with an
> industry-
> imposed signing regime that I don't think is based in PGP or md5/
> shaXXX.
>
> Christian.
>
> On 11-Jul-08, at 12:56 , Brett Porter wrote:
>
>> The current signing mechanism actually works quite well and I had no
>> intention of changing that at this stage. I haven't seen any issues
>> with this, and adding such fine grained lifecycle stages would soon
>> get out of control (and frequent arguments as to the correct order).
>>
>> If it were to be more built in, I would suggest making it a part of
>> <distributionManagement> and the deployment mechanism if anything,
>> but really the current plugin works fine for that.
>>
>> Cheers,
>> Brett
>>
>> On 12/07/2008, at 2:47 AM, Christian Edward Gruber wrote:
>>
>>> Can I suggest that a phase in the default lifecycle be added after
>>> packaging for signing (somewhere). It can have no default binding
>>> plugin (such as integration-test) but if it's there, it's easier to
>>> hook in things at the correct time.
>>>
>>> Or a pre-package and post-package phase which would amount to the
>>> same thing, and be probably more appropriate.
>>>
>>> Or pre-package, package, post-package, package-sign. Why not go
>>> for broke and have a fairly articulated full lifecycle. :)
>>>
>>> Christian.
>>>
>>> On 11-Jul-08, at 12:42 , Brett Porter wrote:
>>>
>>>> Hi,
>>>>
>>>> I've wanted to pick up my work on this for some time and was
>>>> prodded by the general@incubator threads to take another crack at
>>>> this.
>>>>
>>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>>> issue and related branches are linked)
>>>>
>>>> I've created a couple of branches to try integrating the work
>>>> again in as simple and non-intrusive manner (both in code and to
>>>> the user) as possible. I already have commons-openpgp in the
>>>> sandbox from some time ago to deal with processing the signatures
>>>> (it doesn't have any external dependencies other than bouncy
>>>> castle), so I'll integrate that.
>>>>
>>>> If anyone else wants to offer feedback or dive in, you're more
>>>> than welcome!
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: artifact signing feature branches
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Christian, what kind of files are produced with the sig? Are they still
.asc?
-----Original Message-----
From: Christian Edward Gruber [mailto:christianedwardgruber@gmail.com]
Sent: Friday, July 11, 2008 1:24 PM
To: Maven Developers List
Subject: Re: artifact signing feature branches
Incidentally, I presume that there is a provider for PGP that could be
replaced by an alternate signing system if a provider were written for
it? I didn't see it in the wiki, but I have a client with an industry-
imposed signing regime that I don't think is based in PGP or md5/shaXXX.
Christian.
On 11-Jul-08, at 12:56 , Brett Porter wrote:
> The current signing mechanism actually works quite well and I had no
> intention of changing that at this stage. I haven't seen any issues
> with this, and adding such fine grained lifecycle stages would soon
> get out of control (and frequent arguments as to the correct order).
>
> If it were to be more built in, I would suggest making it a part of
> <distributionManagement> and the deployment mechanism if anything,
> but really the current plugin works fine for that.
>
> Cheers,
> Brett
>
> On 12/07/2008, at 2:47 AM, Christian Edward Gruber wrote:
>
>> Can I suggest that a phase in the default lifecycle be added after
>> packaging for signing (somewhere). It can have no default binding
>> plugin (such as integration-test) but if it's there, it's easier to
>> hook in things at the correct time.
>>
>> Or a pre-package and post-package phase which would amount to the
>> same thing, and be probably more appropriate.
>>
>> Or pre-package, package, post-package, package-sign. Why not go
>> for broke and have a fairly articulated full lifecycle. :)
>>
>> Christian.
>>
>> On 11-Jul-08, at 12:42 , Brett Porter wrote:
>>
>>> Hi,
>>>
>>> I've wanted to pick up my work on this for some time and was
>>> prodded by the general@incubator threads to take another crack at
>>> this.
>>>
>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>> issue and related branches are linked)
>>>
>>> I've created a couple of branches to try integrating the work
>>> again in as simple and non-intrusive manner (both in code and to
>>> the user) as possible. I already have commons-openpgp in the
>>> sandbox from some time ago to deal with processing the signatures
>>> (it doesn't have any external dependencies other than bouncy
>>> castle), so I'll integrate that.
>>>
>>> If anyone else wants to offer feedback or dive in, you're more
>>> than welcome!
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Christian Edward Gruber <ch...@gmail.com>.
Incidentally, I presume that there is a provider for PGP that could be
replaced by an alternate signing system if a provider were written for
it? I didn't see it in the wiki, but I have a client with an industry-
imposed signing regime that I don't think is based in PGP or md5/shaXXX.
Christian.
On 11-Jul-08, at 12:56 , Brett Porter wrote:
> The current signing mechanism actually works quite well and I had no
> intention of changing that at this stage. I haven't seen any issues
> with this, and adding such fine grained lifecycle stages would soon
> get out of control (and frequent arguments as to the correct order).
>
> If it were to be more built in, I would suggest making it a part of
> <distributionManagement> and the deployment mechanism if anything,
> but really the current plugin works fine for that.
>
> Cheers,
> Brett
>
> On 12/07/2008, at 2:47 AM, Christian Edward Gruber wrote:
>
>> Can I suggest that a phase in the default lifecycle be added after
>> packaging for signing (somewhere). It can have no default binding
>> plugin (such as integration-test) but if it's there, it's easier to
>> hook in things at the correct time.
>>
>> Or a pre-package and post-package phase which would amount to the
>> same thing, and be probably more appropriate.
>>
>> Or pre-package, package, post-package, package-sign. Why not go
>> for broke and have a fairly articulated full lifecycle. :)
>>
>> Christian.
>>
>> On 11-Jul-08, at 12:42 , Brett Porter wrote:
>>
>>> Hi,
>>>
>>> I've wanted to pick up my work on this for some time and was
>>> prodded by the general@incubator threads to take another crack at
>>> this.
>>>
>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>> issue and related branches are linked)
>>>
>>> I've created a couple of branches to try integrating the work
>>> again in as simple and non-intrusive manner (both in code and to
>>> the user) as possible. I already have commons-openpgp in the
>>> sandbox from some time ago to deal with processing the signatures
>>> (it doesn't have any external dependencies other than bouncy
>>> castle), so I'll integrate that.
>>>
>>> If anyone else wants to offer feedback or dive in, you're more
>>> than welcome!
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Christian Edward Gruber <ch...@gmail.com>.
Fair enough, though I think pre and post implicit phases for many of
the "normal" phases isn't bloat, since it's a regular pattern.
Having said that, one is free to design a custom lifecycle for a
custom type, so I guess it's not that big a deal, and there's
deterministic order of execution for things within each phase (if I'm
not mistaken), so it's not a killer or anything.
christian
On 11-Jul-08, at 12:56 , Brett Porter wrote:
> The current signing mechanism actually works quite well and I had no
> intention of changing that at this stage. I haven't seen any issues
> with this, and adding such fine grained lifecycle stages would soon
> get out of control (and frequent arguments as to the correct order).
>
> If it were to be more built in, I would suggest making it a part of
> <distributionManagement> and the deployment mechanism if anything,
> but really the current plugin works fine for that.
>
> Cheers,
> Brett
>
> On 12/07/2008, at 2:47 AM, Christian Edward Gruber wrote:
>
>> Can I suggest that a phase in the default lifecycle be added after
>> packaging for signing (somewhere). It can have no default binding
>> plugin (such as integration-test) but if it's there, it's easier to
>> hook in things at the correct time.
>>
>> Or a pre-package and post-package phase which would amount to the
>> same thing, and be probably more appropriate.
>>
>> Or pre-package, package, post-package, package-sign. Why not go
>> for broke and have a fairly articulated full lifecycle. :)
>>
>> Christian.
>>
>> On 11-Jul-08, at 12:42 , Brett Porter wrote:
>>
>>> Hi,
>>>
>>> I've wanted to pick up my work on this for some time and was
>>> prodded by the general@incubator threads to take another crack at
>>> this.
>>>
>>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>>> issue and related branches are linked)
>>>
>>> I've created a couple of branches to try integrating the work
>>> again in as simple and non-intrusive manner (both in code and to
>>> the user) as possible. I already have commons-openpgp in the
>>> sandbox from some time ago to deal with processing the signatures
>>> (it doesn't have any external dependencies other than bouncy
>>> castle), so I'll integrate that.
>>>
>>> If anyone else wants to offer feedback or dive in, you're more
>>> than welcome!
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Brett Porter <br...@apache.org>.
The current signing mechanism actually works quite well and I had no
intention of changing that at this stage. I haven't seen any issues
with this, and adding such fine grained lifecycle stages would soon
get out of control (and frequent arguments as to the correct order).
If it were to be more built in, I would suggest making it a part of
<distributionManagement> and the deployment mechanism if anything, but
really the current plugin works fine for that.
Cheers,
Brett
On 12/07/2008, at 2:47 AM, Christian Edward Gruber wrote:
> Can I suggest that a phase in the default lifecycle be added after
> packaging for signing (somewhere). It can have no default binding
> plugin (such as integration-test) but if it's there, it's easier to
> hook in things at the correct time.
>
> Or a pre-package and post-package phase which would amount to the
> same thing, and be probably more appropriate.
>
> Or pre-package, package, post-package, package-sign. Why not go for
> broke and have a fairly articulated full lifecycle. :)
>
> Christian.
>
> On 11-Jul-08, at 12:42 , Brett Porter wrote:
>
>> Hi,
>>
>> I've wanted to pick up my work on this for some time and was
>> prodded by the general@incubator threads to take another crack at
>> this.
>>
>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>> issue and related branches are linked)
>>
>> I've created a couple of branches to try integrating the work again
>> in as simple and non-intrusive manner (both in code and to the
>> user) as possible. I already have commons-openpgp in the sandbox
>> from some time ago to deal with processing the signatures (it
>> doesn't have any external dependencies other than bouncy castle),
>> so I'll integrate that.
>>
>> If anyone else wants to offer feedback or dive in, you're more than
>> welcome!
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Christian Edward Gruber <ch...@gmail.com>.
Can I suggest that a phase in the default lifecycle be added after
packaging for signing (somewhere). It can have no default binding
plugin (such as integration-test) but if it's there, it's easier to
hook in things at the correct time.
Or a pre-package and post-package phase which would amount to the same
thing, and be probably more appropriate.
Or pre-package, package, post-package, package-sign. Why not go for
broke and have a fairly articulated full lifecycle. :)
Christian.
On 11-Jul-08, at 12:42 , Brett Porter wrote:
> Hi,
>
> I've wanted to pick up my work on this for some time and was prodded
> by the general@incubator threads to take another crack at this.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
> issue and related branches are linked)
>
> I've created a couple of branches to try integrating the work again
> in as simple and non-intrusive manner (both in code and to the user)
> as possible. I already have commons-openpgp in the sandbox from some
> time ago to deal with processing the signatures (it doesn't have any
> external dependencies other than bouncy castle), so I'll integrate
> that.
>
> If anyone else wants to offer feedback or dive in, you're more than
> welcome!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Jason van Zyl <ja...@maven.org>.
On 17-Jul-08, at 3:35 AM, Brett Porter wrote:
> I've checked in my work so far on this. It's a pretty small and
> straightforward set of changes and it works for a project using
> signed artifacts and plugins. Of course, it gets very unhappy about
> the distinct lack of signatures in central on most projects.
>
> I am going to look at creating a second repository on central that
> contains only signatures. I'll copy across the ones that already
> exist, and generate them using the shared "I trust the old
> repository" key. I'll have it mod_rewrite anything that isn't a
> detached signature to the old repo, so you can use the alternate URL
> as an "alternate", signed, central repo. It won't take up much space
> (which I'll verify) and I'll not be evolving the signatures at this
> time as it's just a prototype.
>
> Any comments?
>
It's just a prototype. I say go for it and then write it up.
At the same time we have work in Mercury that myself, Oleg, Jesse,
Greg, and Jan have worked on Mercury in a significant way. Shane is
currently working on the new POM builder but he's got some working PGP
work that will be integrated into Mercury as well. Once this work is
done we will propose using that in 2.1 and I see Mercury becoming the
defacto standard for dealing with Maven repositories.
But prototype away!
> Cheers,
> Brett
>
> On 12/07/2008, at 2:42 AM, Brett Porter wrote:
>
>> Hi,
>>
>> I've wanted to pick up my work on this for some time and was
>> prodded by the general@incubator threads to take another crack at
>> this.
>>
>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
>> issue and related branches are linked)
>>
>> I've created a couple of branches to try integrating the work again
>> in as simple and non-intrusive manner (both in code and to the
>> user) as possible. I already have commons-openpgp in the sandbox
>> from some time ago to deal with processing the signatures (it
>> doesn't have any external dependencies other than bouncy castle),
>> so I'll integrate that.
>>
>> If anyone else wants to offer feedback or dive in, you're more than
>> welcome!
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: artifact signing feature branches
Posted by Brett Porter <br...@apache.org>.
I've checked in my work so far on this. It's a pretty small and
straightforward set of changes and it works for a project using signed
artifacts and plugins. Of course, it gets very unhappy about the
distinct lack of signatures in central on most projects.
I am going to look at creating a second repository on central that
contains only signatures. I'll copy across the ones that already
exist, and generate them using the shared "I trust the old repository"
key. I'll have it mod_rewrite anything that isn't a detached signature
to the old repo, so you can use the alternate URL as an "alternate",
signed, central repo. It won't take up much space (which I'll verify)
and I'll not be evolving the signatures at this time as it's just a
prototype.
Any comments?
Cheers,
Brett
On 12/07/2008, at 2:42 AM, Brett Porter wrote:
> Hi,
>
> I've wanted to pick up my work on this for some time and was prodded
> by the general@incubator threads to take another crack at this.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security (the
> issue and related branches are linked)
>
> I've created a couple of branches to try integrating the work again
> in as simple and non-intrusive manner (both in code and to the user)
> as possible. I already have commons-openpgp in the sandbox from some
> time ago to deal with processing the signatures (it doesn't have any
> external dependencies other than bouncy castle), so I'll integrate
> that.
>
> If anyone else wants to offer feedback or dive in, you're more than
> welcome!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org