incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Robot vs. personal KEYS for signing releases
Date Sun, 14 Jun 2015 05:35:50 GMT
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 <cedric.champeau@gmail.com>
wrote:

> 2015-06-08 17:41 GMT+02:00 David Nalley <david@gnsa.us>:
>
> > On Mon, Jun 8, 2015 at 9:40 AM, Cédric Champeau
> > <cedric.champeau@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message