Robot vs. personal KEYS for signing releases

[Roman Shaposhnik <rv...@apache.org>]

Hi!

my recollection is that the collective opinion
was to discourage the use of KEYS of robots
for signing the releases and prefer individuals
do that with their keys.

I remember a thread to that effect, but I cant
google it. Am I misremembering?

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Robot vs. personal KEYS for signing releases

[Cédric Champeau <ce...@gmail.com>]

>
> Would it be possible to sign the robot keys with your own keys?
>
> I think it is possible, yes.

Re: Robot vs. personal KEYS for signing releases

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Jun 8, 2015 at 2:55 PM, Cédric Champeau
<ce...@gmail.com> wrote:
> Well I guess the debate is because of Groovy and our use of robot keys, so
> "should" vs "must". If it's a should, I think we're ok...

Would it be possible to sign the robot keys with your own keys?

The alternative is to sign the release archive with your own key, in
addition to the robot's signature - AFAICS for Groovy that's a single
file to sign.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Robot vs. personal KEYS for signing releases

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sat, Jun 13, 2015 at 10:35 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Cédric,
> you are very vague about it, and it could well be that everything is ok.
> But I suggest that you let infra@ give a opinion about the security level
> of the solution that you running with.
>
> For instance, (IIUIC) one rogue PMC member could compromise the private key
> secretly, and no one would be the wiser.
>
> Also, you even say yourself "Checking the release is a human job." and how
> do you indicate that you have checked a particular release ---> You sign it
> with your (the reviewer) own key. Otherwise, how do you know what you
> reviewed is what is being released?

I would like to take a moment and make a point that I very much share
Niclas' concerns. I have no trust in "collectively owned" keys whatsover.

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Robot vs. personal KEYS for signing releases

[Niclas Hedhman <ni...@hedhman.org>]

Cédric,
you are very vague about it, and it could well be that everything is ok.
But I suggest that you let infra@ give a opinion about the security level
of the solution that you running with.

For instance, (IIUIC) one rogue PMC member could compromise the private key
secretly, and no one would be the wiser.

Also, you even say yourself "Checking the release is a human job." and how
do you indicate that you have checked a particular release ---> You sign it
with your (the reviewer) own key. Otherwise, how do you know what you
reviewed is what is being released?

Niclas

On Tue, Jun 9, 2015 at 6:13 PM, Cédric Champeau <ce...@gmail.com>
wrote:

> 2015-06-08 17:41 GMT+02:00 David Nalley <da...@gnsa.us>:
>
> > On Mon, Jun 8, 2015 at 9:40 AM, Cédric Champeau
> > <ce...@gmail.com> wrote:
> > > We are not using the Apache CI servers for that but our own CI server.
> > IMHO
> > > you should make a difference between building and checking. Building
> > should
> > > be automated as much as possible. Checking the release is a human job.
> > > There are lots of reasons why we stopped releasing from a local
> computer
> > > years ago.
> >
> > Who has access to the keys? How are they secured, and what's the plan
> > for going forward with that? (and this should all be documented) I ask
> > this because I know of more than one project that has had a
> > 'centralized key' to sign with; but which the PMC didn't control; and
> > that eventually caused problems when the person with access to the key
> > disappeared from the community.
> >
>
> The key is on the CI server. All PMC members have access to it. It is also
> on Bintray. I have signed the key too.
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Robot vs. personal KEYS for signing releases

[Cédric Champeau <ce...@gmail.com>]

2015-06-08 17:41 GMT+02:00 David Nalley <da...@gnsa.us>:

> On Mon, Jun 8, 2015 at 9:40 AM, Cédric Champeau
> <ce...@gmail.com> wrote:
> > We are not using the Apache CI servers for that but our own CI server.
> IMHO
> > you should make a difference between building and checking. Building
> should
> > be automated as much as possible. Checking the release is a human job.
> > There are lots of reasons why we stopped releasing from a local computer
> > years ago.
>
> Who has access to the keys? How are they secured, and what's the plan
> for going forward with that? (and this should all be documented) I ask
> this because I know of more than one project that has had a
> 'centralized key' to sign with; but which the PMC didn't control; and
> that eventually caused problems when the person with access to the key
> disappeared from the community.
>

The key is on the CI server. All PMC members have access to it. It is also
on Bintray. I have signed the key too.

Re: Robot vs. personal KEYS for signing releases

[David Nalley <da...@gnsa.us>]

On Mon, Jun 8, 2015 at 9:40 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> We are not using the Apache CI servers for that but our own CI server. IMHO
> you should make a difference between building and checking. Building should
> be automated as much as possible. Checking the release is a human job.
> There are lots of reasons why we stopped releasing from a local computer
> years ago.

Who has access to the keys? How are they secured, and what's the plan
for going forward with that? (and this should all be documented) I ask
this because I know of more than one project that has had a
'centralized key' to sign with; but which the PMC didn't control; and
that eventually caused problems when the person with access to the key
disappeared from the community.

As Jake said, I personally wouldn't entrust keys to the ASF's general
purpose CI infrastructure, but I haven't seen anything that
immediately sets off klaxons in my head.

--David

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Robot vs. personal KEYS for signing releases

[Cédric Champeau <ce...@gmail.com>]

We are not using the Apache CI servers for that but our own CI server. IMHO
you should make a difference between building and checking. Building should
be automated as much as possible. Checking the release is a human job.
There are lots of reasons why we stopped releasing from a local computer
years ago.

2015-06-08 15:36 GMT+02:00 Jake Farrell <jf...@apache.org>:

> No debate, the Apache CI servers are not intended to produce release
> artifacts and should not be used for this purpose. The release manager
> should build the artifacts locally and sign them before uploading them to
> be tested and voted on. Most projects have this process scripted out fully
> and will run the same script run on jenkins and then if a release flag is
> used sign and upload the artifacts accordingly (would also recommend making
> a template of the vote email so links and other details are not hand
> edited). If you would like any examples please let me know
>
> -Jake
>
>
> On Mon, Jun 8, 2015 at 8:55 AM, Cédric Champeau <cedric.champeau@gmail.com
> >
> wrote:
>
> > Well I guess the debate is because of Groovy and our use of robot keys,
> so
> > "should" vs "must". If it's a should, I think we're ok. The reason we use
> > robot signing is automation. We want to avoid as many human intervention
> in
> > the release process as possible. That is to say, in the end, the whole
> > release process should be automated, only checking the artifacts should
> be
> > human based. This is not possible if we involve individual signatures.
> > Basically, for Groovy, before joining Apache, we used to automate
> > everything but checking the artifacts. It worked pretty well so far... Of
> > course one option is to put our private keys into the CI server but
> ahem...
> > I don't really like the idea of having my private key in the wild.
> >
> > 2015-06-08 14:50 GMT+02:00 Jake Farrell <jf...@apache.org>:
> >
> > > The release manager should use their individual key, details on signing
> > and
> > > keys are available at [1]
> > >
> > > -Jake
> > >
> > > [1]: http://www.apache.org/dev/release-signing.html
> > >
> > > On Mon, Jun 8, 2015 at 2:59 AM, Roman Shaposhnik <rv...@apache.org>
> wrote:
> > >
> > > > Hi!
> > > >
> > > > my recollection is that the collective opinion
> > > > was to discourage the use of KEYS of robots
> > > > for signing the releases and prefer individuals
> > > > do that with their keys.
> > > >
> > > > I remember a thread to that effect, but I cant
> > > > google it. Am I misremembering?
> > > >
> > > > Thanks,
> > > > Roman.
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> >
>

Re: Robot vs. personal KEYS for signing releases

[Jake Farrell <jf...@apache.org>]

No debate, the Apache CI servers are not intended to produce release
artifacts and should not be used for this purpose. The release manager
should build the artifacts locally and sign them before uploading them to
be tested and voted on. Most projects have this process scripted out fully
and will run the same script run on jenkins and then if a release flag is
used sign and upload the artifacts accordingly (would also recommend making
a template of the vote email so links and other details are not hand
edited). If you would like any examples please let me know

-Jake


On Mon, Jun 8, 2015 at 8:55 AM, Cédric Champeau <ce...@gmail.com>
wrote:

> Well I guess the debate is because of Groovy and our use of robot keys, so
> "should" vs "must". If it's a should, I think we're ok. The reason we use
> robot signing is automation. We want to avoid as many human intervention in
> the release process as possible. That is to say, in the end, the whole
> release process should be automated, only checking the artifacts should be
> human based. This is not possible if we involve individual signatures.
> Basically, for Groovy, before joining Apache, we used to automate
> everything but checking the artifacts. It worked pretty well so far... Of
> course one option is to put our private keys into the CI server but ahem...
> I don't really like the idea of having my private key in the wild.
>
> 2015-06-08 14:50 GMT+02:00 Jake Farrell <jf...@apache.org>:
>
> > The release manager should use their individual key, details on signing
> and
> > keys are available at [1]
> >
> > -Jake
> >
> > [1]: http://www.apache.org/dev/release-signing.html
> >
> > On Mon, Jun 8, 2015 at 2:59 AM, Roman Shaposhnik <rv...@apache.org> wrote:
> >
> > > Hi!
> > >
> > > my recollection is that the collective opinion
> > > was to discourage the use of KEYS of robots
> > > for signing the releases and prefer individuals
> > > do that with their keys.
> > >
> > > I remember a thread to that effect, but I cant
> > > google it. Am I misremembering?
> > >
> > > Thanks,
> > > Roman.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
>

Re: Robot vs. personal KEYS for signing releases

[Cédric Champeau <ce...@gmail.com>]

Well I guess the debate is because of Groovy and our use of robot keys, so
"should" vs "must". If it's a should, I think we're ok. The reason we use
robot signing is automation. We want to avoid as many human intervention in
the release process as possible. That is to say, in the end, the whole
release process should be automated, only checking the artifacts should be
human based. This is not possible if we involve individual signatures.
Basically, for Groovy, before joining Apache, we used to automate
everything but checking the artifacts. It worked pretty well so far... Of
course one option is to put our private keys into the CI server but ahem...
I don't really like the idea of having my private key in the wild.

2015-06-08 14:50 GMT+02:00 Jake Farrell <jf...@apache.org>:

> The release manager should use their individual key, details on signing and
> keys are available at [1]
>
> -Jake
>
> [1]: http://www.apache.org/dev/release-signing.html
>
> On Mon, Jun 8, 2015 at 2:59 AM, Roman Shaposhnik <rv...@apache.org> wrote:
>
> > Hi!
> >
> > my recollection is that the collective opinion
> > was to discourage the use of KEYS of robots
> > for signing the releases and prefer individuals
> > do that with their keys.
> >
> > I remember a thread to that effect, but I cant
> > google it. Am I misremembering?
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>

Re: Robot vs. personal KEYS for signing releases

[Jake Farrell <jf...@apache.org>]

The release manager should use their individual key, details on signing and
keys are available at [1]

-Jake

[1]: http://www.apache.org/dev/release-signing.html

On Mon, Jun 8, 2015 at 2:59 AM, Roman Shaposhnik <rv...@apache.org> wrote:

> Hi!
>
> my recollection is that the collective opinion
> was to discourage the use of KEYS of robots
> for signing the releases and prefer individuals
> do that with their keys.
>
> I remember a thread to that effect, but I cant
> google it. Am I misremembering?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>