[gentoo-dev] Manifest signing

[gentoo-dev] Manifest signing

[Anthony G. Basile]

Hi everyone,

The issue of Manifest signing came up in #gentoo-hardened channel ...
again.  Its clearly a security issue and yet many manifests in the tree
are still not signed.  Is there any chance that we can agree to reject
unsigned manifests?  Possibly a question for the Council to adjudicate?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Manifest signing

[Tony "Chainsaw" Vroon]

On 29/09/11 16:02, Anthony G. Basile wrote:
> Is there any chance that we can agree to reject
> unsigned manifests?  Possibly a question for the Council to adjudicate?

I am happy to back a mandatory signing policy for the main gentoo-x86
tree. This is a simple yes or no question that the council can vote on.

Regards,
Tony V.

Re: [gentoo-dev] Manifest signing

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

On 29-09-2011 11:02:17 -0400, Anthony G. Basile wrote:
> The issue of Manifest signing came up in #gentoo-hardened channel ...
> again.  Its clearly a security issue and yet many manifests in the tree
> are still not signed.  Is there any chance that we can agree to reject
> unsigned manifests?  Possibly a question for the Council to adjudicate?

Please refer to Mike's thread on this.

http://archives.gentoo.org/gentoo-dev/msg_7210bc8a18140db8f18ff89245efacd5.xml


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: Manifest signing

[Duncan]

Fabian Groffen posted on Thu, 29 Sep 2011 17:09:57 +0200 as excerpted:

> On 29-09-2011 11:02:17 -0400, Anthony G. Basile wrote:
>> The issue of Manifest signing came up in #gentoo-hardened channel ...
>> again.  Its clearly a security issue and yet many manifests in the tree
>> are still not signed.  Is there any chance that we can agree to reject
>> unsigned manifests?  Possibly a question for the Council to adjudicate?
> 
> Please refer to Mike's thread on this.
> 
> http://archives.gentoo.org/gentoo-dev/
msg_7210bc8a18140db8f18ff89245efacd5.xml

Every time this comes up, it gets a bunch of discussion, perhaps a few 
more people start signing (but with dev turnover, I really don't know if 
it gets better over time), and eventually the issue goes back to sleep.

I have a feeling something similar was happening for kernel.org security 
discussions.  Let's not be them in this regard.

In that old thread, the only real issue other than "just doing it" that I 
saw raised was that of the two-stage commit thing.  AFAIK in theory, that 
allows a rather nasty DoS attack, so it does need dealt with, tho a DoS 
worst-case is already better than the current worst-case.

Beyond that, IMO it's now at the "needs a proposal champion to clean it 
up and present it to the council" stage, at least at the "council 
declared priority" level for getting the requirements into repoman, the 
CVS server, and perhaps the PMs (I don't know what stage they're at, 
possibly all they need is a switch flipped?).

Talking about which, at the PM user level, is there a per-repo/overlay 
switch?  If not, it should strongly be considered.

With a proposal champion and a council declared priority, hopefully 
within the year, "the switch" would be ready to be flipped, and a second 
council vote could be taken to flip it.

But, someone with the domain knowledge, both of GPG and of the PMs and 
commit process, needs to step up as the proposal champion and guide it 
thru.  It seems to me we're "almost there", and this is what's needed 
now, for that final push.

In my book, that champion would stand up there along with WilliamH for 
being the guy that finally pushed OpenRC thru to stability (absolutely 
not without the help of others, of course, but it took someone to step up 
and actually be the champion that pushed it thru).  That's not an 
insignificant thing to be able to put on one's CV, BTW, that you were the 
proposal champion that helped with the final push toward tree signing and 
thus general tree security for a community distro like Gentoo. =:^)

Meanwhile, seems to me that Google, et al. could well have sufficient 
interest in this, given Gentoo's status as upstream, to sponsor hardware, 
etc, if needed.

And I'm sure the Gentoo/PR folks would a WHOLE lot rather deal with an 
announcement that Gentoo's tree is now signed and that the PMs now reject 
unsigned by default, BEFORE having to deal with an announcement along the 
lines of kernel.org's recent ones, instead of AFTER. =:\

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Manifest signing

[Robin H. Johnson]

On Thu, Sep 29, 2011 at 07:08:29PM +0000, Duncan wrote:
> Beyond that, IMO it's now at the "needs a proposal champion to clean it 
> up and present it to the council" stage, at least at the "council 
> declared priority" level for getting the requirements into repoman, the 
> CVS server, and perhaps the PMs (I don't know what stage they're at, 
> possibly all they need is a switch flipped?).
It doesn't need cleaning up. I wrote the tree-signing GLEPs a few years
ago, and those were approved by the council, really they just need
updating to a recent Portage and usage.

They provide better support than just getting every developer to sign
the Manifests, because to do so while eclasses are unsigned is a giant
security hole. MetaManifest in the proposal covers that by getting the
entire tree to a state of being signed.

> Talking about which, at the PM user level, is there a per-repo/overlay 
> switch?  If not, it should strongly be considered.
Yes. See layout.conf/repo.conf. Also controls usage of thin Manifests.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Manifest signing

[enno+gentoo]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

Hello,

Am 29.09.2011 17:02, schrieb Anthony G. Basile:
> Hi everyone,
> 
> The issue of Manifest signing came up in #gentoo-hardened channel ...
> again.  Its clearly a security issue and yet many manifests in the tree
> are still not signed.  Is there any chance that we can agree to reject
> unsigned manifests?  Possibly a question for the Council to adjudicate?

I followed the threads about manifest signing with interest and even had
a look at the manifest signing guide [4]. Sounds nice at first view.
But, please correct me, if I'm wrong. I didn't find a place where these
signatures are verified.
Is manifest signing for the infrastructure team, enabling them to verify
the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by
commit signing if the move to git is done ([2])?
If it is (also) for the users, why is there no code for it in portage
anymore [3]?
Okay "why" is clear. Obviously nobody was maintaining it...
I thought about signing the manifests of my overlay. But this is
senseless, if there is no automatic check. I can't think of any user
verifying manifest signatures by hand.
To me it looks like there are repeating complaints about missing
signatures, but I don't see any verification methods for existing
manifest signatures.
At the moment there are 10608 of 15085 manifests signed in my portage
tree. But I can't check them, because I don't have the public keys and
if I fetch them from a public keyserver, I still don't know, if they
really belong to the corresponding Gentoo developers.
Is there some kind of Gentoo Keyring I don't know of?

How does infrastructure team check, if a GPG key belongs to a developer?
The Manifest signing guide [4] simply says "Upload the key to a
keyserver". Everbody can upload a key to the public keyservers. An
attacker, able to modify a signed Manifest, could simply create a new
key on the developers name and use it to sign the modified manifest.
Therefore it must be clear which key really belongs to a dev.

Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete.
This looks like the right place to continue work on Tree Signing.

Regards,
Enno

[1] http://www.gentoo.org/proj/en/glep/glep-0057.html
[2]
http://archives.gentoo.org/gentoo-dev/msg_91813ec042831af2fd688e7ecfae4943.xml
[3]
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4c16649d121dca977b3c569f03c5d1b194b635d4
[4] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6
[5]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/robbat2/tree-signing-gleps/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Manifest signing

[Robin H. Johnson]

On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gentoo@groeper-berlin.de wrote:
> I followed the threads about manifest signing with interest and even had
> a look at the manifest signing guide [4]. Sounds nice at first view.
> But, please correct me, if I'm wrong. I didn't find a place where these
> signatures are verified.
> Is manifest signing for the infrastructure team, enabling them to verify
> the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by
> commit signing if the move to git is done ([2])?
Developer signing is radically altered in the face of git yes, that's
one of the reasons not much has happened there. But the other larger
reason is that developer signing pales in importance to the signature
chain between infra->user.

> If it is (also) for the users, why is there no code for it in portage
> anymore [3]?
Hmm, I hadn't see that removal, but it makes sense unless the entire
tree is developer-signed, which isn't likely to happen soon.

> Okay "why" is clear. Obviously nobody was maintaining it...
The code worked when I used it...

> I thought about signing the manifests of my overlay. But this is
> senseless, if there is no automatic check. I can't think of any user
> verifying manifest signatures by hand.
There's a chicken & egg problem with most signing. You need to
communicate the valid keys out of band from the actual repo.
Maybe the layman data is a good place for that, but until such a
location is figured out, you have zero security gain (if the 'correct'
keys are only listed in a file in the repo, any attacker just replaces
that when he puts his other content in).

> How does infrastructure team check, if a GPG key belongs to a developer?
> The Manifest signing guide [4] simply says "Upload the key to a
> keyserver". Everbody can upload a key to the public keyservers. An
> attacker, able to modify a signed Manifest, could simply create a new
> key on the developers name and use it to sign the modified manifest.
> Therefore it must be clear which key really belongs to a dev.
Developers specify in their LDAP data what keys are theirs, and this
gets exported here, amongst other places:
http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml

There was a prototype keyserver at one point as well, and I can generate
new keyrings if needed based on the LDAP data.

> Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete.
> This looks like the right place to continue work on Tree Signing.
Those were the draft copies, which were finalized into GLEP 57..61.
You are correct that there are two unfinished GLEPs in that directory:
02-developer-process-security
03-gnupg-policies-and-handling

Of those, 03 can probably be written at this point.
02 is going to change radically when git comes into play.


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Manifest signing

[enno+gentoo]

[-- Attachment #1: Type: text/plain, Size: 4817 bytes --]

Hi,

Am 02.11.2011 17:11, schrieb Robin H. Johnson:
> On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gentoo@groeper-berlin.de wrote:
>> I followed the threads about manifest signing with interest and even had
>> a look at the manifest signing guide [4]. Sounds nice at first view.
>> But, please correct me, if I'm wrong. I didn't find a place where these
>> signatures are verified.
>> Is manifest signing for the infrastructure team, enabling them to verify
>> the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by
>> commit signing if the move to git is done ([2])?
> Developer signing is radically altered in the face of git yes, that's
> one of the reasons not much has happened there. But the other larger
> reason is that developer signing pales in importance to the signature
> chain between infra->user.
If developer signing works, it could act as a trust chain between
(developer->)infra->user. And it could work with good old default
"emerge --sync", not only with emerge-webrsync and snapshots.
If its senseless to do anything in this area as long as the move to git
isn't done, there is no need to wine about unsigned manifests.
At least if there isn't anyone checking developer signatures at the moment.

>> If it is (also) for the users, why is there no code for it in portage
>> anymore [3]?
> Hmm, I hadn't see that removal, but it makes sense unless the entire
> tree is developer-signed, which isn't likely to happen soon.
I don't agree here. Of course the implementation shouldn't stop the user
from installing an unsigned package at the moment. But it could give a
warning instead and ask the user what to do.
In this way developers are encouraged to sign their packages (to make
the warning go away) and users get the ability to check the signatures,
that already exist.
Key problem here is the Gentoo keyring (how to ensure it didn't get
manipulated).

>> Okay "why" is clear. Obviously nobody was maintaining it...
> The code worked when I used it...
I didn't check it. All I have are the commit messages and the
feature-removal of the portage team.

>> I thought about signing the manifests of my overlay. But this is
>> senseless, if there is no automatic check. I can't think of any user
>> verifying manifest signatures by hand.
> There's a chicken & egg problem with most signing. You need to
> communicate the valid keys out of band from the actual repo.
> Maybe the layman data is a good place for that, but until such a
> location is figured out, you have zero security gain (if the 'correct'
> keys are only listed in a file in the repo, any attacker just replaces
> that when he puts his other content in).
Of course. But security is always worth thinking about it.
First step: What are the possibilities the check the signatures? FAIL.
In my case some (most?) of the users of my overlay should know my GPG
key already. The web of trust works here. The drawback for possible
other users would be a false sense of security.

>> How does infrastructure team check, if a GPG key belongs to a developer?
>> The Manifest signing guide [4] simply says "Upload the key to a
>> keyserver". Everbody can upload a key to the public keyservers. An
>> attacker, able to modify a signed Manifest, could simply create a new
>> key on the developers name and use it to sign the modified manifest.
>> Therefore it must be clear which key really belongs to a dev.
> Developers specify in their LDAP data what keys are theirs, and this
> gets exported here, amongst other places:
> http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml
Thanks for the enlightenment. But I doubt, if this should be the way to
go (see below).

> There was a prototype keyserver at one point as well, and I can generate
> new keyrings if needed based on the LDAP data.
This could be okay for a first creation. Later I would prefer something
like Debian does:
http://keyring.debian.org/replacing_keys.html
That way you would decouple the LDAP and the keyring and trust only the
data, that is already in the keyring (somebody whose key is already in
the keyring signing the request for a new key).
See also: http://keyring.debian.org/
Perhaps the prototype keyserver already did something like that.

> 
>> Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete.
>> This looks like the right place to continue work on Tree Signing.
> Those were the draft copies, which were finalized into GLEP 57..61.
> You are correct that there are two unfinished GLEPs in that directory:
> 02-developer-process-security
> 03-gnupg-policies-and-handling
> 
> Of those, 03 can probably be written at this point.
> 02 is going to change radically when git comes into play.
I had those 2 in mind, yes.

Regards,
Enno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Manifest signing

[Robin H. Johnson]

On Thu, Nov 03, 2011 at 10:55:52PM +0100, enno+gentoo@groeper-berlin.de wrote:
> >> If it is (also) for the users, why is there no code for it in portage
> >> anymore [3]?
> > Hmm, I hadn't see that removal, but it makes sense unless the entire
> > tree is developer-signed, which isn't likely to happen soon.
> I don't agree here. Of course the implementation shouldn't stop the user
> from installing an unsigned package at the moment. But it could give a
> warning instead and ask the user what to do.
> In this way developers are encouraged to sign their packages (to make
> the warning go away) and users get the ability to check the signatures,
> that already exist.
> Key problem here is the Gentoo keyring (how to ensure it didn't get
> manipulated).
Distributing the keyring itself signed is how Debian does it IIRC.

> > There's a chicken & egg problem with most signing. You need to
> > communicate the valid keys out of band from the actual repo.
> > Maybe the layman data is a good place for that, but until such a
> > location is figured out, you have zero security gain (if the 'correct'
> > keys are only listed in a file in the repo, any attacker just replaces
> > that when he puts his other content in).
> Of course. But security is always worth thinking about it.
> First step: What are the possibilities the check the signatures? FAIL.
> In my case some (most?) of the users of my overlay should know my GPG
> key already. The web of trust works here. The drawback for possible
> other users would be a false sense of security.
That's why I say the gpg key should be in the layman data.
Overlays team, do you think this is reasonable?

> > There was a prototype keyserver at one point as well, and I can generate
> > new keyrings if needed based on the LDAP data.
> This could be okay for a first creation. Later I would prefer something
> like Debian does:
> http://keyring.debian.org/replacing_keys.html
> That way you would decouple the LDAP and the keyring and trust only the
> data, that is already in the keyring (somebody whose key is already in
> the keyring signing the request for a new key).
> See also: http://keyring.debian.org/
> Perhaps the prototype keyserver already did something like that.
The Debian model was discussed, and the main problem was finding enough
people to sign the keys near all of the devs, esp. if you require
meeting in person.

You need two factors to be able to change your GPG key on file anyway.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85