[gentoo-dev] rejecting unsigned commits

[gentoo-dev] rejecting unsigned commits

[Mike Frysinger]

is there any reason we should allow people to commit unsigned
Manifest's anymore ?  generating/posting/enabling a gpg key is
ridiculously easy and there's really no excuse for a dev to not have
done this already.

when i look at the tree, the signed stats are stupid low:
$ find *-* -maxdepth 2 -name Manifest | wc -l
14438
$ find *-* -maxdepth 2 -name Manifest -exec grep -l 'BEGIN PGP
SIGNATURE' {} + | wc -l
6032

this is especially important for the people doing arch keywording
since they make a ton of commits.  i'm looking at you armin76.
-mike

Re: [gentoo-dev] rejecting unsigned commits

[Markos Chandras]

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

On Thu, Mar 24, 2011 at 05:59:45PM -0400, Mike Frysinger wrote:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?  generating/posting/enabling a gpg key is
> ridiculously easy and there's really no excuse for a dev to not have
> done this already.
> 
> when i look at the tree, the signed stats are stupid low:
> $ find *-* -maxdepth 2 -name Manifest | wc -l
> 14438
> $ find *-* -maxdepth 2 -name Manifest -exec grep -l 'BEGIN PGP
> SIGNATURE' {} + | wc -l
> 6032
> 
> this is especially important for the people doing arch keywording
> since they make a ton of commits.  i'm looking at you armin76.
> -mike
> 
Yes, I recall a similar thread in the past but I can't find it. Whilst I
am always signing my commits  I can't really see a good argument on why
we should/should not do it.

Regards,
-- 
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

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

Re: [gentoo-dev] rejecting unsigned commits

[Olivier Crête]

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

On Thu, 2011-03-24 at 17:59 -0400, Mike Frysinger wrote:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?  generating/posting/enabling a gpg key is
> ridiculously easy and there's really no excuse for a dev to not have
> done this already.

I didn't know we still allowed that.. I guess the CVS server should just
reject unsigned Manifests..


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rejecting unsigned commits

[Brian Harring]

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

On Thu, Mar 24, 2011 at 06:08:53PM -0400, Olivier Crête wrote:
> On Thu, 2011-03-24 at 17:59 -0400, Mike Frysinger wrote:
> > is there any reason we should allow people to commit unsigned
> > Manifest's anymore ?  generating/posting/enabling a gpg key is
> > ridiculously easy and there's really no excuse for a dev to not have
> > done this already.
> 
> I didn't know we still allowed that.. I guess the CVS server should just
> reject unsigned Manifests..

Reject, and email an alias of folk who will go fix the manifest.  Keep 
in mind since it's a two stage commit for cvs, the checksums are left 
out of sync if we just flat out reject unsigned manifests and ignore 
the fallout.

~brian

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

Re: [gentoo-dev] rejecting unsigned commits

[Mike Frysinger]

On Thu, Mar 24, 2011 at 8:21 PM, Brian Harring wrote:
> On Thu, Mar 24, 2011 at 06:08:53PM -0400, Olivier Crête wrote:
>> On Thu, 2011-03-24 at 17:59 -0400, Mike Frysinger wrote:
>> > is there any reason we should allow people to commit unsigned
>> > Manifest's anymore ?  generating/posting/enabling a gpg key is
>> > ridiculously easy and there's really no excuse for a dev to not have
>> > done this already.
>>
>> I didn't know we still allowed that.. I guess the CVS server should just
>> reject unsigned Manifests..
>
> Reject, and email an alias of folk who will go fix the manifest.  Keep
> in mind since it's a two stage commit for cvs, the checksums are left
> out of sync if we just flat out reject unsigned manifests and ignore
> the fallout.

the fallout is said dev fixes their setup or they lose commit access

i dont expect the rejection to go into effect $now, so people not
signing have plenty of time to start doing so
-mike

Re: [gentoo-dev] rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 544 bytes --]

> i dont expect the rejection to go into effect $now, so people not
> signing have plenty of time to start doing so

Is the additional effort of implementing this for CVS with the current two-stage commit even worth it?

I.e. would it not make more sense to wait _with the automated rejection_ until we finally made the Big Jump To Git?!

This does not mean that we cannot prepare everything else in the meantime...

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rejecting unsigned commits

[Petteri Räty]

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

On 03/24/2011 11:59 PM, Mike Frysinger wrote:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?  generating/posting/enabling a gpg key is
> ridiculously easy and there's really no excuse for a dev to not have
> done this already.
> 

Also submitting the quizzes require you to have a GPG key. This probably
hasn't been a priority before all the tree can be signed. I think it
would be idea to start preparing for that by requiring people sign as
you said.

Regards,
Petteri


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

[gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

http://bugs.gentoo.org/360363
-mike

Re: [gentoo-dev] rejecting unsigned commits

[Mike Gilbert]

On Thu, Mar 24, 2011 at 5:59 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?  generating/posting/enabling a gpg key is
> ridiculously easy and there's really no excuse for a dev to not have
> done this already.
>

Is there some plan to make verification of signed Manifests
easy/automatic for end users? Or am I misunderstanding the point of
Manifest signing?

Re: [gentoo-dev] rejecting unsigned commits

[Mike Frysinger]

On Thu, Mar 24, 2011 at 6:28 PM, Mike Gilbert wrote:
> Is there some plan to make verification of signed Manifests easy/automatic for end users?

the end goal is for it to be transparent when it works.  emerge itself
would check things as part of its digest verification.

as to the current state of emerge's support, i dont know.  be nice if
Zac showed up to SCALE so we could sign keys :p.
-mike

Re: [gentoo-dev] rejecting unsigned commits

[Rémi Cardona]

Le 24/03/2011 22:59, Mike Frysinger a écrit :
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?  generating/posting/enabling a gpg key is
> ridiculously easy and there's really no excuse for a dev to not have
> done this already.

I, for one, have never signed my Manifests because I've always found
GnuPG to be a major PITA.

With that being said, I do understand the rationale of signing them and
I'll adapt.

However, is there a howto or something explaining how to work
_efficiently_ with GPG? How do I avoid having to type my pass-phrase for
every commit?

Cheers,

Rémi

PS, wasn't manifest-signing supposed to become moot once we moved to git?

[gentoo-dev] Re: rejecting unsigned commits

[Diego Elio Pettenò]

Il giorno gio, 24/03/2011 alle 23.42 +0100, Rémi Cardona ha scritto:
> 
> 
> However, is there a howto or something explaining how to work
> _efficiently_ with GPG? How do I avoid having to type my pass-phrase
> for
> every commit?

Setup gpg-agent with a one-week passphrase caching and standard socket,
remove gnome-keyring interface to gpg, and that's about it :P

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Thu, Mar 24, 2011 at 6:47 PM, Diego Elio Pettenò wrote:
> Il giorno gio, 24/03/2011 alle 23.42 +0100, Rémi Cardona ha scritto:
>> However, is there a howto or something explaining how to work
>> _efficiently_ with GPG? How do I avoid having to type my pass-phrase
>> for every commit?
>
> Setup gpg-agent with a one-week passphrase caching and standard socket,
> remove gnome-keyring interface to gpg, and that's about it :P

indeed ... i put "default-cache-ttl 999999" into my ~/.gnupg/gpg-agent.conf

as for gpg-agent itself, if you use net-misc/keychain, it takes care
of launching gpg-agent if it's installed
-mike

Re: [gentoo-dev] rejecting unsigned commits

[Mike Frysinger]

On Thu, Mar 24, 2011 at 6:42 PM, Rémi Cardona wrote:
> PS, wasn't manifest-signing supposed to become moot once we moved to git?

not in the least.  git only provides SHA1 which is not
cryptographically strong, and we will still be mirroring only the
latest checkout via rsync.  the hashs in git require the entire tree
in order to validate.
-mike

Re: [gentoo-dev] rejecting unsigned commits

[Jeroen Roovers]

On Thu, 24 Mar 2011 17:59:45 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?  

Funny that. I only started doing that Yesterday. It had been on my TODO
for a couple of years. :)


     jer

Re: [gentoo-dev] rejecting unsigned commits

[Antoni Grzymala]

Jeroen Roovers dixit (2011-03-25, 00:50):

> On Thu, 24 Mar 2011 17:59:45 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
> 
> > is there any reason we should allow people to commit unsigned
> > Manifest's anymore ?  
> 
> Funny that. I only started doing that Yesterday. It had been on my TODO
> for a couple of years. :)

Does that get us any closer to GLEPs 57, 58, 59 (or generally
approaching the tree-signing/verifying group of problems)?

Regards,

-- 
[a]

Re: [gentoo-dev] rejecting unsigned commits

[Mike Frysinger]

On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
> Jeroen Roovers dixit (2011-03-25, 00:50):
>> On Thu, 24 Mar 2011 17:59:45 -0400 Mike Frysinger wrote:
>> > is there any reason we should allow people to commit unsigned
>> > Manifest's anymore ?
>>
>> Funny that. I only started doing that Yesterday. It had been on my TODO
>> for a couple of years. :)
>
> Does that get us any closer to GLEPs 57, 58, 59 (or generally
> approaching the tree-signing/verifying group of problems)?

yes
-mike

[gentoo-dev] Re: rejecting unsigned commits

[Torsten Veller]

* Mike Frysinger <vapier@gentoo.org>:
> On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
[Manifest signing]
> > Does that get us any closer to GLEPs 57, 58, 59 (or generally
> > approaching the tree-signing/verifying group of problems)?
> 
> yes

I think, it's a "no".
The MetaManifest GLEP relies on a signed top-level "MetaManifest" which
hashes all sub Manifests, whether they are signed or not doesn't matter.

I don't see a major advantage to signed portage snapshots we already
offer today.


Do you want to reject signed commits if
- keys are not publicly available [1]
- signatures are from expired keys [2]
- keys are revoked [3]
- keys are not listed in userinfo.xml (current or former devs) [4]

[1] https://bugs.gentoo.org/205405
[2] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_expired_keys.txt
[3] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_revoked_keys.txt
[4] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/keys_in_use.txt

Re: [gentoo-dev] Re: rejecting unsigned commits

[Patrick Lauer]

On 03/25/11 15:15, Torsten Veller wrote:
> * Mike Frysinger <vapier@gentoo.org>:
>> On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
> [Manifest signing]
>>> Does that get us any closer to GLEPs 57, 58, 59 (or generally
>>> approaching the tree-signing/verifying group of problems)?
>>
>> yes
> 
> I think, it's a "no".
> The MetaManifest GLEP relies on a signed top-level "MetaManifest" which
> hashes all sub Manifests, whether they are signed or not doesn't matter.

I'd say that those are two independent issues. But by starting to figure
out how to force signed commits for everyone we at least get the
infrastructure done.

As long as we have no strict guidelines I don't see any advantage of
using signed commits, so I've never used them. Getting a coherent policy
for that sounds like a really good idea
(key length, expiry time, availability on keyservers etc.)
> 
> I don't see a major advantage to signed portage snapshots we already
> offer today.
> 
> 
> Do you want to reject signed commits if
> - keys are not publicly available [1]
> - signatures are from expired keys [2]
> - keys are revoked [3]
> - keys are not listed in userinfo.xml (current or former devs) [4]

Yes, yes, yes, and yes :)
But since we don't have policies in place yet it's a bit of a mess right
now.

So. What parameters do we need to agree on?

And what's a realistic timeframe *if* we decide to go ahead with it?

Waiting for good answers :)

Patrick
-- 
Patrick Lauer         http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1645 bytes --]


> 
> Do you want to reject signed commits if
> - keys are not publicly available [1]

Yes, since that defies the purpose of the signature.

> - signatures are from expired keys [2]

Yes if the signature was made after expiration. (Dont know if that is even 
possible.)
No if the signature was made while the key was valid. (Otherwise our whole 
portage tree would time out at some point.)

> - keys are revoked [3]

Yes.

> - keys are not listed in userinfo.xml (current or former devs) [4]

Yes. 
However, for the former devs we might need an extra list to prevent 
"expiration on retirement", and treat the keys as if they expired on 
retirement date (compare above).

Does that make sense?

Of course now we can add additional requirements:

* The key must have an userid that refers to an official Gentoo e-mail 
address. E.g. dilfridge@gentoo.org

Very important and easily implemented.

* The userid should have some specific "default string" in its comment field, 
like "Gentoo manifest signing key".

Not so important but also easily implemented.

* The key should be signed by some central instance for automated validity 
check.

Here things get hairy. How about having recruiter/infra team sign a dev's key 
on completion of the recruitment process? Just a first thought...

* The central instance should be able to reliably revoke a key.

Add a revocation list in a portage tree directory? Or is this just shooting 
yourself into the foot backwards through the eye?

Cheers, A

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Antoni Grzymala]

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

Andreas K. Huettel dixit (2011-03-25, 09:53):

> > Do you want to reject signed commits if
> > - keys are not publicly available [1]
> 
> Yes, since that defies the purpose of the signature.
> 
> > - signatures are from expired keys [2]
> 
> Yes if the signature was made after expiration. (Dont know if that is even 
> possible.)
> No if the signature was made while the key was valid. (Otherwise our whole 
> portage tree would time out at some point.)
> 
> > - keys are revoked [3]
> 
> Yes.
> 
> > - keys are not listed in userinfo.xml (current or former devs) [4]
> 
> Yes. 
> However, for the former devs we might need an extra list to prevent 
> "expiration on retirement", and treat the keys as if they expired on 
> retirement date (compare above).
> 
> Does that make sense?
> 
> Of course now we can add additional requirements:
> 
> * The key must have an userid that refers to an official Gentoo e-mail 
> address. E.g. dilfridge@gentoo.org
> 
> Very important and easily implemented.
> 
> * The userid should have some specific "default string" in its comment field, 
> like "Gentoo manifest signing key".
> 
> Not so important but also easily implemented.
> 
> * The key should be signed by some central instance for automated validity 
> check.
> 
> Here things get hairy. How about having recruiter/infra team sign a dev's key 
> on completion of the recruitment process? Just a first thought...

I think this is an important requirement however it's quite difficult
to conduct reliably. A normal keysigning process usually requires
knowing one personally (and perhaps verifying fingerprints over a
phone with voice verification), seeing one's ID personally and the
like. This is probably unfeasible in the Gentoo development
environment (I'm not a dev, though, so I'm just guessing).

As a weaker but possibly useful workaround Gentoo Infra could just
publish a signed list of trusted developer keys for any given moment.

> * The central instance should be able to reliably revoke a key.
> 
> Add a revocation list in a portage tree directory? Or is this just shooting 
> yourself into the foot backwards through the eye?

Revoking a signature on a key is possible (unless a key has been
nrsigned) and makes sense (assuming those who verify update all
relevant keys).

-- 
[a]

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

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1160 bytes --]

> > * The key should be signed by some central instance for automated
> > validity check.
> > 
> > Here things get hairy. How about having recruiter/infra team sign a dev's
> > key on completion of the recruitment process? Just a first thought...
> 
> I think this is an important requirement however it's quite difficult
> to conduct reliably. A normal keysigning process usually requires
> knowing one personally (and perhaps verifying fingerprints over a
> phone with voice verification), seeing one's ID personally and the
> like. This is probably unfeasible in the Gentoo development
> environment (I'm not a dev, though, so I'm just guessing).

Well, as long as the signed UID is the specific "Gentoo address UID", this 
should be no problem, since...

* the signature proves the key belongs to the e-mail address, nothing else
* the e-mail address is given to the owner of the key during recruitment

Meaning nobody is certifying something that he/she does not know already by 
definition.

Please point out any thinkos... :)

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/25/2011 05:44 AM, Andreas K. Huettel wrote:
>>> * The key should be signed by some central instance for automated
>>> validity check.
>>>
>>> Here things get hairy. How about having recruiter/infra team sign a dev's
>>> key on completion of the recruitment process? Just a first thought...
>>
>> I think this is an important requirement however it's quite difficult
>> to conduct reliably. A normal keysigning process usually requires
>> knowing one personally (and perhaps verifying fingerprints over a
>> phone with voice verification), seeing one's ID personally and the
>> like. This is probably unfeasible in the Gentoo development
>> environment (I'm not a dev, though, so I'm just guessing).
> 
> Well, as long as the signed UID is the specific "Gentoo address UID", this 
> should be no problem, since...
> 
> * the signature proves the key belongs to the e-mail address, nothing else
> * the e-mail address is given to the owner of the key during recruitment
> 
> Meaning nobody is certifying something that he/she does not know already by 
> definition.
> 
> Please point out any thinkos... :)
> 

This is 100% correct. We are not attempting to verify identity. Whether
or not my name is Dane Smith is a moot point. All that matters is that I
am the person that the Gentoo recruiters granted access to.

I cannot stress how important some of this is. It's bad if a binary
distro doesn't sign their code, but in some ways it's even worse for us.
An ebuild can do most anything. If someone were to want to insert some
nastiness into say, openssl, all they have to do is hijack an rsync
mirror, insert their patch, change the ebuild a smidge, and run and
hide. And no one would be any the wiser. The only difference is that
unlike a binary distro where a user can't verify anything (easily), at
least one of ours can always look at the ebuilds / patches.

(Not to mention they could also hack their nastiness into the openssl
tarball, change the manifest, and then run and hide. Same effect, no
notice at the ebuild level.)

For those who got bored at line two it all comes down to:

Sign. Your. STUFF!

Your friendly neighborhood paranoid,

- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- QA / Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNjIAtAAoJEEsurZwMLhUxVFAP/3aXbJb+00wM95Dht/aBT31S
vjsjODbx7/9IL5nxdVumDH6+M21pfa7e0xx1aFsUNvjJNl1jSfH44nsvvjRSkGKq
b8bliwpG++wnQ18Gll1J48XTawLCPKh5HKCQWoRmQPwk7oEkVxXmph/V5/S8PdvL
Y9HM7niA6TeIKtdDjtd/AqgdIizDlrU8a4ovdxrt4MdhPoBSs4CT5BUQszgOEWah
LW/nt/Ir3bL2aML60QBmoxapbCBYSrpn0cqBoBCvOhgTzWWOpAamBV21HxBhiAnE
EzAXYAm8IJH4HWwQp4ar0e/TCo7/mty3mx/lspAFuX4fOXwVgfCS53wtpT7nKvoA
Homy0Q1ZnVMU/bXP5tdvszzPcfRoqfvjO4qU8MlqvlHLKf/RF1Om3kJRYONKTYxo
EDtrT093kRNwI2s3RrrWyJ14Kj6QsKAylsO9KbD5+h+xH/LG1+uWpxxtm0S88A//
qSkU/kP1TRJW7+PxYiodBu5rlqcW+v6JK+jXwTecz96QVrYvsBq6QTBvHODpsxlI
CFBePa23LEbPqq+vnQSrSLXrbeqV9nw4vgvMiU9PHbiWuPDks37xh4mtQY0u/5C9
R4U7VG1sQ0yZQSH0I9HP8v6ZNz99xdyH+VDDJzIvBGdpif1CPyGA4DNmhfvmzpaC
0zqc8QcUe5rJRV5N2zmb
=T/Hi
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: rejecting unsigned commits

[Jeroen Roovers]

On Fri, 25 Mar 2011 10:44:31 +0100
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> * the signature proves the key belongs to the e-mail address, nothing
> else

Anyone could generate a signature with one of my @g.o e-mail addresses
in it, then pass themselves off as myself, right? If they then trick you
into thinking that I sent the mail you received, signed with their key,
they're all set. Having the "right" e-mail address in the key would not
improve anything.

> * the e-mail address is given to the owner of the key during
> recruitment

It's been a while, but I am certain I did not have a @gentoo.org
address yet _during_ recruitment, and I was instead asked to provide an
address that I _did_ already use. It looks like that still has not
changed.[1] Looking at the e-mail from that time, it seems I had been
asked to sign my SSH key with it and send it to recruiters@.


     jer


[1] http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2

Re: [gentoo-dev] Re: rejecting unsigned commits

[Michał Górny]

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

On Fri, 25 Mar 2011 09:53:01 +0100
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Of course now we can add additional requirements:
> 
> * The key must have an userid that refers to an official Gentoo
> e-mail address. E.g. dilfridge@gentoo.org

I think this is pretty useless assuming we're already wanting
to limit the amount of keys trusted to a specific list.

> * The userid should have some specific "default string" in its
> comment field, like "Gentoo manifest signing key".

What's the point of this? I don't see a reason to enforce a dev to have
a dedicated Manifest signing key, and even more I don't see a reason to
add such comments to normal keys.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1011 bytes --]

> > * The key must have an userid that refers to an official Gentoo
> > e-mail address. E.g. dilfridge@gentoo.org
> 
> I think this is pretty useless assuming we're already wanting
> to limit the amount of keys trusted to a specific list.

See the remark in a separate sub-thread about signing...

Deciding key validity based on signatures is a lot better than based on a central list. Otherwise we are just duplicating existing infrastructure.

> > * The userid should have some specific "default string" in its
> > comment field, like "Gentoo manifest signing key".
> 
> What's the point of this? I don't see a reason to enforce a dev to have
> a dedicated Manifest signing key, and even more I don't see a reason to
> add such comments to normal keys.

Well it's probably not necessary. It might simplify identification of the UID that determines key validity though.


-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
> Of course now we can add additional requirements:
>
> * The key must have an userid that refers to an official Gentoo e-mail
> address. E.g. dilfridge@gentoo.org

no.  there's no reason for this requirement, and it prevents proxy
maintenance long term.  e-mail addresses do not verify identity,
verifying identify verifies identity.  this is the point of the web of
trust.
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/25/2011 02:46 PM, Mike Frysinger wrote:
> On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
>> Of course now we can add additional requirements:
>>
>> * The key must have an userid that refers to an official Gentoo e-mail
>> address. E.g. dilfridge@gentoo.org
> 
> no.  there's no reason for this requirement, and it prevents proxy
> maintenance long term.  e-mail addresses do not verify identity,
> verifying identify verifies identity.  this is the point of the web of
> trust.
> -mike
> 

We are somewhat limited in the amount that we can verify "identity."
Sure you can get a decent web of trust from signing the keys of people
you've met at conferences, however, there will be people outside of that
web. What we need to verify is rather that the person who made the
commit is someone who is authorized to make the commit and that it was
in no way tampered with.

- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- QA / Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNjOWQAAoJEEsurZwMLhUxKnMQAKKbtRbdIDK++MpSWEJKg4Un
gBhlPRtZ4CxoNGh5DRcgHD4k6eq8a7fE9MjPuge9/prDfLjmFW7nr0FJ9olZzXoG
F5qvsCerpPNN2dw6ccCotP3UQCPyjADdZ4mRvmcMdlWdzluq3rD631mzEw8+m4cM
EJz1DF2q9Oi2Zca8wxlPXf3+11NqHt2bnMWQhkoWFDtAVLD+rPoIsZsV6mRz+ip7
uWX8TiMoZCJgRAA0NqCVph4B3kGzn+xcwHuvlcoK87j7ShZKJD4sh0W6GOoewq9A
Ei+Idsgx+POYg7t8q5khD2tJQRBBSEnBqARgnMJnun6WA4w+Wls7Hw9nidttBXuY
isbdOUy4t7G2W2l7juG83RuGxLJ4UQMKcD4dWMKcpgHmU5ZXl6W2q+lgMIf5oz6x
SFk6UGxwf8QbJVL65tKQRytZfdJS1zGvtfdofTHLIYMofhobZH9TqqhZLr7Nf0l3
wPukQA7I212bfCjP3VNApVdAtAIJk353hWloGk0xOQBzMqHraIX7hnPxdHg+qVOo
MjCTt9JnlynkwKqPUdrtyjTH3vXpHuyBqy4wSwpfoaJDetDAtsHOcoZxK9LR4xtl
FQ8AdYADSDmMPSsbd1SrxLA4XM7BHJx1LolxzlGz4s08SnCaIHoVD9EChRr3IkL2
OFwD0Su4CZ9mQBjsYy8K
=kuoA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 2:57 PM, Dane Smith wrote:
> On 03/25/2011 02:46 PM, Mike Frysinger wrote:
>> On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
>>> Of course now we can add additional requirements:
>>>
>>> * The key must have an userid that refers to an official Gentoo e-mail
>>> address. E.g. dilfridge@gentoo.org
>>
>> no.  there's no reason for this requirement, and it prevents proxy
>> maintenance long term.  e-mail addresses do not verify identity,
>> verifying identify verifies identity.  this is the point of the web of
>> trust.
>
> We are somewhat limited in the amount that we can verify "identity."
> Sure you can get a decent web of trust from signing the keys of people
> you've met at conferences, however, there will be people outside of that
> web.

creating one "tree key" which signs all developer keys listed in LDAP
is trivial to do

> What we need to verify is rather that the person who made the
> commit is someone who is authorized to make the commit and that it was
> in no way tampered with.

you're validating only that the machine with access to the private
keys pushed up the commit.  hopefully the only person with said
machine is the one we recruited.
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Alec Warner]

On Fri, Mar 25, 2011 at 7:28 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Fri, Mar 25, 2011 at 2:57 PM, Dane Smith wrote:
>> On 03/25/2011 02:46 PM, Mike Frysinger wrote:
>>> On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
>>>> Of course now we can add additional requirements:
>>>>
>>>> * The key must have an userid that refers to an official Gentoo e-mail
>>>> address. E.g. dilfridge@gentoo.org
>>>
>>> no.  there's no reason for this requirement, and it prevents proxy
>>> maintenance long term.  e-mail addresses do not verify identity,
>>> verifying identify verifies identity.  this is the point of the web of
>>> trust.
>>
>> We are somewhat limited in the amount that we can verify "identity."
>> Sure you can get a decent web of trust from signing the keys of people
>> you've met at conferences, however, there will be people outside of that
>> web.
>
> creating one "tree key" which signs all developer keys listed in LDAP
> is trivial to do
>
>> What we need to verify is rather that the person who made the
>> commit is someone who is authorized to make the commit and that it was
>> in no way tampered with.
>
> you're validating only that the machine with access to the private
> keys pushed up the commit.  hopefully the only person with said
> machine is the one we recruited.
> -mike
>
>

Coming back around to the earlier discussion of Alice who has her key
signed by robbat2 (because he loves keysigning parties) and then Alice
breaks into cvs.gentoo.org and commits evil code into the tree.  If we
cannot stop this attack because we are relying on a chain of trust
(and Alice is in the chain) can we at least detect the attack?

As it appears to me; I am much more likely to somehow manipulate the
chain in trust in an incorrect way (such as at a keysigning hibjib) as
opposed to adding some random strangers key to a master list on
dev.gentoo.org or in LDAP.  The former action is essentially an
innocent act with non-obvious (to me) repercussions and the latter is
an act with really only one intent.

I don't care about GPG at all.  I hate it.  I don't want to know how
it works and I don't want developers who are in the same boat as me to
fuck it up because they don't know what they are doing.  I don't have
commit-bit to gentoo-x86 so I don't have a big stake in this ;)

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 10:38 PM, Alec Warner wrote:
> Coming back around to the earlier discussion of Alice who has her key
> signed by robbat2 (because he loves keysigning parties) and then Alice
> breaks into cvs.gentoo.org and commits evil code into the tree.  If we
> cannot stop this attack because we are relying on a chain of trust
> (and Alice is in the chain) can we at least detect the attack?

verifying identity isnt the same as listing who we trust.  this is the
point Robin is making when he says he wants to list all trusted keys
in LDAP.  from there, we could create a file signed by an infra "tree
key" and keep only the trusted keys in it.
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1096 bytes --]

> > * The key must have an userid that refers to an official Gentoo e-mail
> > address. E.g. dilfridge@gentoo.org
> 
> no.  there's no reason for this requirement, and it prevents proxy
> maintenance long term.  e-mail addresses do not verify identity,
> verifying identify verifies identity.  this is the point of the web of
> trust.

So what sort of identity do you want to verify? Seriously, at the moment when I got my commit bit, noone from Gentoo had ever met me in person, and for sure noone had ever had a look at my passport or any similar legal document. The only established connection was my preexisting gpg key, which was then coupled to my gentoo account.

As for proxy maintenance, isn't the whole point of that that the proxied maintainers are not devs and do not have (commit access | a gentoo.org user id)? I do not understand how this would prevent proxy maintenance. 

Now, e.g. overlay access is a different matter. But first things first.


-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 3:50 PM, Andreas K. Huettel wrote:
>> > * The key must have an userid that refers to an official Gentoo e-mail
>> > address. E.g. dilfridge@gentoo.org
>>
>> no.  there's no reason for this requirement, and it prevents proxy
>> maintenance long term.  e-mail addresses do not verify identity,
>> verifying identify verifies identity.  this is the point of the web of
>> trust.
>
> So what sort of identity do you want to verify? Seriously, at the moment when I got my commit bit, noone from Gentoo had ever met me in person, and for sure noone had ever had a look at my passport or any similar legal document. The only established connection was my preexisting gpg key, which was then coupled to my gentoo account.

and no where do we require you to generate a gpg key bound to the
Gentoo e-mail address.  we require you to provide a gpg key only.
like you said *right here*, we have 0 information to identify you, and
using a Gentoo e-mail address adds *nothing* to that.  so why add a
completely useless requirement ?

> As for proxy maintenance, isn't the whole point of that that the proxied maintainers are not devs and do not have (commit access | a gentoo.org user id)? I do not understand how this would prevent proxy maintenance.

uhh, you already pointed out how -- git.  if i pull updates from a
proxy maintainer, it's going to have his signing.
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1957 bytes --]

> > So what sort of identity do you want to verify? Seriously, at the moment when I got my commit bit, noone from Gentoo had ever met me in person, and for sure noone had ever had a look at my passport or any similar legal document. The only established connection was my preexisting gpg key, which was then coupled to my gentoo account.
> 
> and no where do we require you to generate a gpg key bound to the
> Gentoo e-mail address.  we require you to provide a gpg key only.
> like you said *right here*, we have 0 information to identify you, and
> using a Gentoo e-mail address adds *nothing* to that.  so why add a
> completely useless requirement ?

Because, pointing out the obvious, the key can contain all sorts of random true or false information. I could have an user id saying "Barack Obama <president@whitehouse.gov>". 

To be able to do key validation based on gpg's mechanisms, an userid needs to be signed. As e.g. Scarabeus and Wired can confirm, I'm definitely not Barack Obama, but for less obvious cases the validity of the provided identity may be unclear.

Now, if I add an userid "<dilfridge@gentoo.org>" to my key, this userid does not contain any information that is not already verified and "in the Gentoo infra data". So, this one userid could be signed immediately by a central instance without any further fuss.

It's imho not a hard requirement, but it considerably eases administration. So why not require it for devs?


> > As for proxy maintenance, isn't the whole point of that that the proxied maintainers are not devs and do not have (commit access | a gentoo.org user id)? I do not understand how this would prevent proxy maintenance.
> 
> uhh, you already pointed out how -- git.  if i pull updates from a
> proxy maintainer, it's going to have his signing.

Point taken...


-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 4:33 PM, Andreas K. Huettel wrote:
>> and no where do we require you to generate a gpg key bound to the
>> Gentoo e-mail address.  we require you to provide a gpg key only.
>> like you said *right here*, we have 0 information to identify you, and
>> using a Gentoo e-mail address adds *nothing* to that.  so why add a
>> completely useless requirement ?
>
> Because, pointing out the obvious, the key can contain all sorts of random true or false information. I could have an user id saying "Barack Obama <president@whitehouse.gov>".
>
> To be able to do key validation based on gpg's mechanisms, an userid needs to be signed. As e.g. Scarabeus and Wired can confirm, I'm definitely not Barack Obama, but for less obvious cases the validity of the provided identity may be unclear.
>
> Now, if I add an userid "<dilfridge@gentoo.org>" to my key, this userid does not contain any information that is not already verified and "in the Gentoo infra data". So, this one userid could be signed immediately by a central instance without any further fuss.

first off, fix your e-mail client.  this long line crap is ridiculous.

second, anyone can add/remove e-mail addresses.  we arent verifying
e-mail addresses, we're verifying keys.  the *only* thing that matters
is that the key we have on file (0xabcd) is the one that was used to
sign.

> It's imho not a hard requirement, but it considerably eases administration. So why not require it for devs?

it makes 0 difference to administration
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 2394 bytes --]


> first off, fix your e-mail client.  this long line crap is ridiculous.

:) ever heard of flowed text? absolutely no need to get aggressive...

> second, anyone can add/remove e-mail addresses.  we arent verifying
> e-mail addresses, we're verifying keys.  

Unfortunately you are misunderstanding the GnuPG trust model here. As a third 
party you are not signing someone's key, but someone's userid associated with 
that key.

> the *only* thing that matters
> is that the key we have on file (0xabcd) is the one that was used to
> sign.

That's a policy decision. Basically there are several ways to go by 
implementing our own trust model.

1) Rely on an existing list of keys somewhere distributed in portage, and 
automatically trust all keys in that list.
VERY BAD, because if someone manipulates the portage tree he/she can 
manipulate that list as well. I'm pretty confident however you actually meant 
option 2) or 3):

2) Rely on an existing keyring somewhere distributed in portage; the file (not 
the keys themselves) is signed with a master key.
Is a very clumsy workaround.
Pros: you can exactly decide what keys are used and trusted, without thinking 
about GnuPG's inner workings.
Cons: People tend to modify their keys. Add user ids. Add new subkeys. Expire 
or revoke subkeys. Revoke userids. (My photo in the key is pretty old by now. 
:o) Whenever anything of this happens, the key file changes, needs to be re-
signed by infra and re-uploaded.

3) Rely on an existing key list somewhere distributed in portage; the list 
file with the key id's (not the keys themselves) is signed with a master key.
Is a mediocre and potentially insecure workaround.
Pros: you can exactly decide what keys are used and trusted, without thinking 
about GnuPG's inner workings. A user can edit his key and the key remains 
trusted.
Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed 
people around?)

4) Rely on an existing list of keys somewhere distributed in portage and 
possibly somewhere else (keyservers); a key userid is signed with a master 
key. Work with GnuPG's well-tested and well-thought-out trust relationships.
Back to start, time to re-read the entire thread... :)

Am I missing something?

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Robin H. Johnson]

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

On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote:
> 3) Rely on an existing key list somewhere distributed in portage; the list 
...
> Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed 
> people around?)
You can use the long-format key IDs if you want.
0xB27B944E34884E85 is my long-form key.

> Am I missing something?
In my tree-signing GLEPs, I explicitly pointed out that the developer
signing of content only had real value for the developer->CVS
part of the chain. Specifically, that while building the rsync tree for
distribution, we can verify that the content we are preparing was indeed
from a developer.

Please re-read GLEP57.

Everything in this thread been attempting to apply solutions to 'Process
#1' (developer->infrastructure) to provide direct security for the end
user after 'Process #2' (infrastructure->mirrors->users).

What can we be certain of?
1. Developers should be signing manifests.
2. Infrastructure should be verifying those commits before pushing out
   to rsync.
3. Regardless of their choice of rsync or websync, users need to be able
   to verify that the tree that left Infrastructure was not modified in
   transit.

RegI see so many bad ideas mentioned in this thread. The suggestions to
keep a gpg-agent with a very long passphrase TTL just provides a massive
new security hole: 
===
Attacker breaks into developer's system, has access to SSH agent and GPG
agent thanks to software like keychain, now can commit as that
developer.
===
Is this the easiest attack? No, certainly not, looking at mirrors
mirror, potentially a running deliberate selective malicious mirror
would be much easier.

-- 
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

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

Re: [gentoo-dev] Re: rejecting unsigned commits

["Paweł Hajdan, Jr."]

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

On 3/28/11 2:05 AM, Robin H. Johnson wrote:
> I see so many bad ideas mentioned in this thread. The suggestions to
> keep a gpg-agent with a very long passphrase TTL just provides a massive
> new security hole: 
> ===
> Attacker breaks into developer's system, has access to SSH agent and GPG
> agent thanks to software like keychain, now can commit as that
> developer.

If a dev machine is compromised, the attacker can install a keylogger
and sniff the passphrase. Or he can wait for the dev to enter the
password into gpg-agent and then use it. Or pop up a fake passphrase
dialog box. There many other things that can happen at that point.


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

Re: [gentoo-dev] Re: rejecting unsigned commits

[Robin H. Johnson]

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

On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote:
> 3) Rely on an existing key list somewhere distributed in portage; the list 
> file with the key id's (not the keys themselves) is signed with a master key.
> Is a mediocre and potentially insecure workaround.
> Pros: you can exactly decide what keys are used and trusted, without thinking 
> about GnuPG's inner workings. A user can edit his key and the key remains 
> trusted.
> Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed 
> people around?)
1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids)
2. Clear-sign L, produces L'
3. Include L' in /metadata/ during rsync content build.
3.1. Provide all L' files in a trusted Git repository for historical reference.
4. Tree-sign per GLEP58, such that signed list is included.

Pros:
- L' is plaintext and works well w/ rsync deltas.

Security weakpoints:
- Introduces new weak point if attacker can compromise the automated
  clear-signing service of #2.

> 4) Rely on an existing list of keys somewhere distributed in portage and 
> possibly somewhere else (keyservers); a key userid is signed with a master 
> key. Work with GnuPG's well-tested and well-thought-out trust relationships.
> Back to start, time to re-read the entire thread... :)
What does this actually add over #3 in terms of security?

-- 
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

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

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1591 bytes --]

> > 3) 
> 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids)
> 2. Clear-sign L, produces L'
> 3. Include L' in /metadata/ during rsync content build.
> 3.1. Provide all L' files in a trusted Git repository for historical reference.
> 4. Tree-sign per GLEP58, such that signed list is included.
> 
> Pros:
> - L' is plaintext and works well w/ rsync deltas.

> Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed 
> people around?)
> - Introduces new weak point if attacker can compromise the automated
>   clear-signing service of #2.
> 
> > 4) Rely on an existing list of keys somewhere distributed in portage and 
> > possibly somewhere else (keyservers); a key userid is signed with a master 
> > key. Work with GnuPG's well-tested and well-thought-out trust relationships.
> > Back to start, time to re-read the entire thread... :)
> What does this actually add over #3 in terms of security?

I don't know. I am basically worried that we are using a well-tested cryptosystem in a hackish way and cannot fully estimate the consequences. (Which is why I hoped someone more knowledgable could comment. I may know approximately how to use gpg, and may have some basic knowledge of the maths behind it, but I have no clue of the data structures and software internals.)

I'd say, here the burden of proof is on you.
(i.e. that the signed list of long keyids is as secure as a list of signed keys)

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/27/2011 08:13 PM, Robin H. Johnson wrote:
> On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote:
>> 3) Rely on an existing key list somewhere distributed in portage; the list 
>> file with the key id's (not the keys themselves) is signed with a master key.
>> Is a mediocre and potentially insecure workaround.
>> Pros: you can exactly decide what keys are used and trusted, without thinking 
>> about GnuPG's inner workings. A user can edit his key and the key remains 
>> trusted.
>> Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed 
>> people around?)
> 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids)
> 2. Clear-sign L, produces L'
> 3. Include L' in /metadata/ during rsync content build.
> 3.1. Provide all L' files in a trusted Git repository for historical reference.
> 4. Tree-sign per GLEP58, such that signed list is included.
> 
> Pros:
> - L' is plaintext and works well w/ rsync deltas.
> 
> Security weakpoints:
> - Introduces new weak point if attacker can compromise the automated
>   clear-signing service of #2.
> 
>> 4) Rely on an existing list of keys somewhere distributed in portage and 
>> possibly somewhere else (keyservers); a key userid is signed with a master 
>> key. Work with GnuPG's well-tested and well-thought-out trust relationships.
>> Back to start, time to re-read the entire thread... :)
> What does this actually add over #3 in terms of security?
> 

This is an extremely non-trivial question. You're talking about signing
each individual key's fingerprint vs generating a list of key
fingerprints (hashes of the key), concatenating them all, hashing THAT,
and then signing that hash.

- From a cryptologic point of view, I would be *extremely* impressed with
anyone that can find a proof of security that shows that those two are
equivalent.

Simple(ish) example. By creating a list you're introducing a lot of data
that is then getting hashed. Now, from a cryptologic point of view, I
would *not* attack the signature per se, but rather the underlying hash
of the list. By providing a large file with lots of data, there are
attacks against (some) has functions that can make use of this (Small
changes in the file that will result in the same hash with probability
greater than normal). (Anyone know off the cuff what hash is actually
used?)

Now, the other method would require having to single out each hash on
it's own, and the underlying key that it hashed. That data is harder to
deal with because you have to manipulate one key into another *valid*
key(a difficult task to have it still be valid) and have it come out
with the same hash. Whereas with the file, who cares if they invalidate
another key, as long as they can get their hash into the file and have
the hash for the sig come out the same.

Point being, what it adds / subtracts is not a simple question. Crypto
is a funny beast, and is best not trifled with unless you understand the
underlying math / the current attacks etc (And even then, don't do it
=P). Do I think that using #4 gives us a huge difference over #3, even
with my years of study on this topic I would not even begin to try to
answer that. Chances are the difference is negligible for our *needs*
(see below), but I don't think it's negligible in the true sense of
security.

Having said that we aren't exactly talking about securing the end all be
all. We just want to be able to verify with a reasonable degree of
certainty that the tree is in a good state and that it wasn't tampered
with. Do we really need the end all be all, I somehow doubt it.

- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- QA / Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNkLnkAAoJEEsurZwMLhUxV64P/1AbiEkcbouFd/XZ50aq/BsC
LRjlUC5GbCpBL1MBTigP1OWO0HT8JvBEKJPAbwChr+KSQqtk3/HOcaoRTlJDz3hf
iG7NrKkh4VECwErshFpzS1/D0D7M2qFXABat7DE/lPmFrIpI96XSd+ZAnjLMtM0g
RoFOAyJ3s3CEIKeG3n448TQagpHkAGinzgkmtA8NZRUf/ziukA7Gk7lQGC+e9YIE
MViWW4bBB1PQq4XL5in58JH2ohQBx49+RgeovdREnTWFJlDsHbxIZN3JTV8EHq7a
8xpni/uPLCbW3XGS2G3x/L7f8yPJOqEyTPROU3s+YGDtZkDYwDI1bn+k2Fnu+3a7
kkFyp4aRrajiFE4WK20iBnnPJn1knfR47O6UEP4aZu/GCC3s/3fJP5pVNlnla7mU
5RXJ1j6Tj3MQoCBdbGypEaVYJf1ZiJGdpUYOHpi4XL2R3mh8XsmnEF53pdp7GOk/
wHfuKvvZ5uKtYawj8QhVB8+Y97kTNYc7t7OIShpAZb0SoyUN+ZGoal4pDASkSM15
uATdmilb7z5JIEKiQ0lLwjdLjJJq5imgpB4YuQBqiF3sKmH8N9Qf5+kCRxvSE09y
lq1hWqppGX+H4CvA5FPRkB7/Qvg2prmwfdIqDlGWfMlR2KLsFoIzRyjKnL1xSCgn
eX/hTD9umMkzOho7l1eL
=h4nm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: rejecting unsigned commits

[Antoni Grzymala]

Torsten Veller dixit (2011-03-25, 08:15):

> * Mike Frysinger <vapier@gentoo.org>:
> > On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
> [Manifest signing]
> > > Does that get us any closer to GLEPs 57, 58, 59 (or generally
> > > approaching the tree-signing/verifying group of problems)?
> > 
> > yes
> 
> I think, it's a "no".
> The MetaManifest GLEP relies on a signed top-level "MetaManifest" which
> hashes all sub Manifests, whether they are signed or not doesn't matter.
> 
> I don't see a major advantage to signed portage snapshots we already
> offer today.

It's just that for everyday use we (perspective of users, possibly
only me) would like to have the ability of easy and automated
verifying of Manifest GPG signatures whether we (r)sync, webrsync or
use a manually downloaded snapshot, with same level of assurance as in
other major distros (Debian, RH).

Regards,

-- 
[a]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Michał Górny]

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

On Fri, 25 Mar 2011 08:15:32 +0100
Torsten Veller <ml-en@veller.net> wrote:

> Do you want to reject signed commits if
> - keys are not publicly available [1]

We'll need to define what does 'public availability' exactly mean? Does
that mean a specific keyserver?

> - keys are revoked [3]

How about manifests signed before the key was revoked?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 755 bytes --]

> > Do you want to reject signed commits if
> > - keys are not publicly available [1]
> 
> We'll need to define what does 'public availability' exactly mean? Does
> that mean a specific keyserver?

Good point. Although most keyservers synchronize each other, it might make sense to define an additional location such as e.g. a keyring for download on www.gentoo.org.

> > - keys are revoked [3]
> 
> How about manifests signed before the key was revoked?

And about keys being revoked by a revocation certificate that was generated long time ago "just in case" (as even our docs recommend)... Yes I know this is a mess.


-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 10:33 AM, Michał Górny wrote:
> On Fri, 25 Mar 2011 08:15:32 +0100 Torsten Veller wrote:
>> - keys are revoked [3]
>
> How about manifests signed before the key was revoked?

you cant do this at commit time (computers cant predict the future),
so it has no bearing on the original idea

people who need to revoke their key are responsible for either
notifying the Gentoo community of the issue and verifying that all the
commits in the tree before their revocation were actually made by them
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 3:15 AM, Torsten Veller <ml-en@veller.wrote:
> * Mike Frysinger <vapier@gentoo.org>:
>> On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
> [Manifest signing]
>> > Does that get us any closer to GLEPs 57, 58, 59 (or generally
>> > approaching the tree-signing/verifying group of problems)?
>>
>> yes
>
> I think, it's a "no".
> The MetaManifest GLEP relies on a signed top-level "MetaManifest" which
> hashes all sub Manifests, whether they are signed or not doesn't matter.

that's *one* of the three gleps

> Do you want to reject signed commits if
> - keys are not publicly available [1]

no.  e-mail warnings will be issued so that the dev can upload it
after the fact.

> - signatures are from expired keys [2]

not generally an issue since gpg itself will not allow it, but i guess
we can be paranoid about it on the server to avoid people locally
turning back their clocks after having snipped someones expired key.

we might want to add an automatic e-mail warning to the developer when
their key is about to expire (like 1 week).

> - keys are revoked [3]

yes

> - keys are not listed in userinfo.xml (current or former devs) [4]

no.  you can sign a key with your personal key and that's good enough.
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote:
> we might want to add an automatic e-mail warning to the developer when
> their key is about to expire (like 1 week).

on 2nd thought, no need.  we'll let repoman handle it locally.
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Rich Freeman]

On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> - keys are revoked [3]
>
> yes
>

To facilitate this, should we pick a preferred keyserver or two?  Devs
of course are welcome to use others also, but if we're going to check
for revocations, we should specify where devs should upload them to in
order to make sure they hit the tree/etc.

The preference need not be strictly applied, but even though those
keyservers are supposed to talk to each other I've found that I get
fairly different results if I refresh against various ones.

Rich

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 2:33 PM, Rich Freeman wrote:
> On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote:
>>> - keys are revoked [3]
>>
>> yes
>
> To facilitate this, should we pick a preferred keyserver or two?  Devs
> of course are welcome to use others also, but if we're going to check
> for revocations, we should specify where devs should upload them to in
> order to make sure they hit the tree/etc.
>
> The preference need not be strictly applied, but even though those
> keyservers are supposed to talk to each other I've found that I get
> fairly different results if I refresh against various ones.

in practice, i think we've been requiring hkp://subkeys.pgp.net
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Robin H. Johnson]

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

On Fri, Mar 25, 2011 at 02:36:14PM -0400, Mike Frysinger wrote:
> > To facilitate this, should we pick a preferred keyserver or two?  Devs
> > of course are welcome to use others also, but if we're going to check
> > for revocations, we should specify where devs should upload them to in
> > order to make sure they hit the tree/etc.
> >
> > The preference need not be strictly applied, but even though those
> > keyservers are supposed to talk to each other I've found that I get
> > fairly different results if I refresh against various ones.
> in practice, i think we've been requiring hkp://subkeys.pgp.net
Subkeys.pgp.net is a rotation that's been a bit buggy of late.
Of the 5 IPs in it right now:
- 2 respond to pings, but not connections
- 1 totally unreachable
- 2 that work, but have slightly different versions of my key.

The SKS rotation seems to be much better, and kingtaco was looking at
running an additional SKS instance within Gentoo as our offical key
point (also useful for speeding up fetching keys in verification).

x-hkp://pool.sks-keyservers.net
http://sks-keyservers.net/status/
http://sks-keyservers.net/overview-of-pools.php

-- 
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

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

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 348 bytes --]

> The SKS rotation seems to be much better, and kingtaco was looking at
> running an additional SKS instance within Gentoo as our offical key
> point (also useful for speeding up fetching keys in verification).

Good idea.

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1070 bytes --]

> > Do you want to reject signed commits if
> > - keys are not publicly available [1]
> 
> no.  e-mail warnings will be issued so that the dev can upload it
> after the fact.

Why? I'm pretty sure someone will forget. (Or try to trick the system.)

> > - keys are revoked [3]
> 
> yes

Only if the signature was made after the date/time of the revocation.

> > - keys are not listed in userinfo.xml (current or former devs) [4]
> 
> no.  you can sign a key with your personal key and that's good enough.

Heh. Yes, if there is a validity that can be checked in an automated way. Which means a signature on the userid. A chain of trust can of course be implemented in many ways, but requiring the user to download the entire strong set is not an option. :o)

The @gentoo.org email addresses are advantageous because they provide a pre-existing identification. Which is as strong as we will ever get with this mechanism (I think).

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 3:57 PM, Andreas K. Huettel wrote:
> The @gentoo.org email addresses are advantageous because they provide a pre-existing identification. Which is as strong as we will ever get with this mechanism (I think).

no, it really doesnt.  when we make someone a dev, they give us a ssh
key and a gpg key.  that is all we need.  the gpg key being bound to a
@gentoo.org e-mail address is completely meaningless.
-mike

Re: [gentoo-dev] rejecting unsigned commits

[Peter Volkov]

В Чтв, 24/03/2011 в 17:59 -0400, Mike Frysinger пишет:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ? 

Why? Without policy on how we do that and more importantly how we check
that signing makes no sense...

-- 
Peter.

Re: [gentoo-dev] rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 553 bytes --]

On Friday 25 March 2011 11:11:12 Peter Volkov wrote:
> В Чтв, 24/03/2011 в 17:59 -0400, Mike Frysinger пишет:
> > is there any reason we should allow people to commit unsigned
> > Manifest's anymore ? 
> 
> Why? Without policy on how we do that and more importantly how we check
> that signing makes no sense...
> 

I guess it's more about starting somewhere and getting required stuff into place step by step...

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rejecting unsigned commits

[Mike Frysinger]

On Fri, Mar 25, 2011 at 6:11 AM, Peter Volkov wrote:
> В Чтв, 24/03/2011 в 17:59 -0400, Mike Frysinger пишет:
>> is there any reason we should allow people to commit unsigned
>> Manifest's anymore ?
>
> Why? Without policy on how we do that and more importantly how we check
> that signing makes no sense...

so you want to wait until we have a 100% fully automated checking
system in place before even attempting the first 1% ?  that doesnt
make much sense ... you have to start somewhere.

there's also nothing stopping people from verifying packages right now
by picking some keys to trust.  i can certainly verify a lot of
packages by following the web of trust that starts at my key.
-mike

Re: [gentoo-dev] rejecting unsigned commits

["Paweł Hajdan, Jr."]

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

On 3/24/11 10:59 PM, Mike Frysinger wrote:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?  generating/posting/enabling a gpg key is
> ridiculously easy and there's really no excuse for a dev to not have
> done this already.

Firstly, I'm excited we're moving towards a signed portage tree.

We can start with a repoman warning (yellow) and a transition period.

> when i look at the tree, the signed stats are stupid low:
> $ find *-* -maxdepth 2 -name Manifest | wc -l
> 14438
> $ find *-* -maxdepth 2 -name Manifest -exec grep -l 'BEGIN PGP
> SIGNATURE' {} + | wc -l
> 6032

If I'm interpreting the data correctly, about 43% of Manifest files are
signed. That's not too bad, I was expecting something more like 5%.

By the way, is it acceptable to use the same GPG key for e-mail and
signing packages?

Paweł Hajdan, Jr.


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

Re: [gentoo-dev] rejecting unsigned commits

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/25/2011 07:55 AM, "Paweł Hajdan, Jr." wrote:
> On 3/24/11 10:59 PM, Mike Frysinger wrote:
>> is there any reason we should allow people to commit unsigned
>> Manifest's anymore ?  generating/posting/enabling a gpg key is
>> ridiculously easy and there's really no excuse for a dev to not have
>> done this already.
> 
> Firstly, I'm excited we're moving towards a signed portage tree.
> 
> We can start with a repoman warning (yellow) and a transition period.
> 
>> when i look at the tree, the signed stats are stupid low:
>> $ find *-* -maxdepth 2 -name Manifest | wc -l
>> 14438
>> $ find *-* -maxdepth 2 -name Manifest -exec grep -l 'BEGIN PGP
>> SIGNATURE' {} + | wc -l
>> 6032
> 
> If I'm interpreting the data correctly, about 43% of Manifest files are
> signed. That's not too bad, I was expecting something more like 5%.
> 
> By the way, is it acceptable to use the same GPG key for e-mail and
> signing packages?

Yes. In fact, I'd recommend it. Saves having to try to keep track of 2
keys / dev.

Having said that, for those that just use "keys" for e-mails (most of
us), it would make more sense to use full blow SSL certs in the long run.
(Mathematically, same thing. But a cert needs to be signed by a CA, and
we should ideally maintain a Gentoo CA.) I need to get up to speed with
the GLEP's pertaining to this. Let's just say I have a fair bit of
experience in this field. I may be able to offer some ideas /
suggestions. I would very much like to see this happen.

But for the meantime, yes, it's safe.

- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- QA / Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNjIO0AAoJEEsurZwMLhUxlsIP/2oaWnkWr160fj8027WA3Jbe
oI5dXXvZr2RDMxFXKcyx0qiTfVlhVClJIBn8wANf41uKmMh6azIN5Ug4cDk++0ku
qYXvIne4W65TCifU44h80AAOEVBLQwN+d2VCeq7/qu6qJp9PT1SIzCaZZCtRAvOK
NwH5ZuUTrcewa/SbADIwP2hbQiLs8m241XJNNWGcIgflbO0OhcvUPlLM6/fUS56X
364EUGDo/TAAtkrIhWKKD2xsRoPmmO2uE7euPNhI4pFGUbKXVtb5Lb/qY9iLDgYy
PciHr2yFwOY1P16hr51Dbo8b5rPAncIHJFBUBHd89OnZHCwkBUP1z7l1J13NfClw
/hoYQe0DO/CrWz2pKF4I3pxP1MnULKKB2ib8RFswCJY2mxKvGeGJoQyZpT/GtCGb
vN8o20Kd3Ci+CEpeIo3sqxt04kNoMvMLEq9ZJ++a8c0wijX63ChRL5/+qRxzGDtc
I9pN34RDuAuUck0Wp+R/TTG4Bjh5ixQkeh199NoqjNLA02rE0QVElm7PlIJxg36/
pp101gH68H0t6EGAFrnGHAG6w/8yAz+Mcm+4WLjpDAPSMXYahZXOCKFn9WV0WgBS
e0EG2xr8BD7SqUrZRSlxjGsbFVCVaGvS9qFO4e2B4dKPy1mjwcTdBQRGZOfd3kGM
WDV73IcPr2K9cQFJD+Te
=yiPl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rejecting unsigned commits

[Michał Górny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 25 Mar 2011 07:59:49 -0400
Dane Smith <c1pher@gentoo.org> wrote:

> Having said that, for those that just use "keys" for e-mails (most of
> us), it would make more sense to use full blow SSL certs in the long
> run. (Mathematically, same thing. But a cert needs to be signed by a
> CA, and we should ideally maintain a Gentoo CA.) I need to get up to
> speed with the GLEP's pertaining to this. Let's just say I have a
> fair bit of experience in this field. I may be able to offer some
> ideas / suggestions. I would very much like to see this happen.

How about Gentoo Foundation funding devs a full blown X509 client
certs?

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk2MqicACgkQnGSe5QXeB7uMJwCfZ2vnDNdN1HyI9Jzcz9ddPnHO
EBwAni9LaXlGcyCp8Hj/MtD0VVSdQoRj
=dtD+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rejecting unsigned commits

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 765 bytes --]

> > Having said that, for those that just use "keys" for e-mails (most of
> > us), it would make more sense to use full blow SSL certs in the long
> > run. (Mathematically, same thing. But a cert needs to be signed by a
> > CA, and we should ideally maintain a Gentoo CA.) I need to get up to
> > speed with the GLEP's pertaining to this. Let's just say I have a
> > fair bit of experience in this field. I may be able to offer some
> > ideas / suggestions. I would very much like to see this happen.
> 
> How about Gentoo Foundation funding devs a full blown X509 client
> certs?

Please dont go for the SSL bloat... just my 2ct...

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rejecting unsigned commits

["Paweł Hajdan, Jr."]

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

On 3/25/11 3:43 PM, Michał Górny wrote:
> How about Gentoo Foundation funding devs a full blown X509 client
> certs?

Let's get signing and verifying working first, and then consider
anything that requires funding.


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

Re: [gentoo-dev] rejecting unsigned commits

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/25/2011 11:04 AM, "Paweł Hajdan, Jr." wrote:
> On 3/25/11 3:43 PM, Michał Górny wrote:
>> How about Gentoo Foundation funding devs a full blown X509 client
>> certs?
> 
> Let's get signing and verifying working first, and then consider
> anything that requires funding.
> 

+1

We do not need to get paid for X509 certs. We control portage. We
control the manifests. We do not need some third party CA to control the
certs used for signing. We have the infrastructure to do it ourselves.
For free. With us in control of the revocation etc.

- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- QA / Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNjK7xAAoJEEsurZwMLhUxfCMP+gNozbZ7aVFl3xejgDOoAych
ttvHp0bDHhIzBd+hO+GvQm6RSm/keHaBi3hX6Sv0IoxK3VARK4xZ7QHrgk2xEr1V
4+vIv44NBpEKbmF5ilm/hWReq1CXpRnef5aL+mdlfGY3FvCVrJjeaMEu15I/TwkJ
wD0fqYSZxZsHLoH0UCnCEew5MJlL8oT21vOVwXbSdZJ2YlpHoAjgR6AOmOTPl+pJ
2ZHnQ7H+tuQr8PxH50rEba6MyrEG0Djgg8NI+w0dNgZcrWm2ODA6o6pdmh+yXlS4
PzvSbwDXe4K6E5i3LHjVAd4OFWS2SY6mLNrBHYR0cI0D0ZtMY3Tab3MksIvuPFaY
X8WwZq5+oEXZgr2poeaKHl9FIoPTqa7eFQkQA3oOPGVb2T3vwpY4JinPvj4Eb5VN
Yd/GnJonbuWtUx6+98b0rBmjhu51vjh7T7BTThKJbuBIJ5KH9NynOAHWpTk6ZyBf
IIMoiEbL/zIr6ZJlIlBP5RlMOHrE2rP+e6D4mzmDOvVT4lIRhr25eCsh3k+K6lJ3
bbuYCCEaowmyMe/oEwrDPzuAdG+N3v4qjB7IvGebSKfv8PSqIBxOOiejAkeFKHFP
Z+2xE65eaAHrr3F2sp+FwhWF9SQy4AAP+wjt1NLrdJGAHasvpn3Dp8rQ9eJq0XFJ
HaUJZLyeEjWwe8md+jF4
=0aS+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rejecting unsigned commits

[Eray Aslan]

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

On 2011-03-25 1:59 PM, Dane Smith wrote:
> Having said that, for those that just use "keys" for e-mails (most of
> us), it would make more sense to use full blow SSL certs in the long run.

Please no.  PKI is a naive design and for all intents and purposes will
remain a pipe-dream.  All security relationships that is worth anything
is bilateral and no trusted third party is willing to accept enough risk
to warrent full trust.

Using public keys for auth is a good security model and the rest of x509
certs is just unnecessary overhead.  Let's not go there.  GPG is good
enough.
-- 
Eray Aslan
Developer, Gentoo Linux       eras <at> gentoo.org


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

[gentoo-dev] Re: rejecting unsigned commits

[Mike Frysinger]

for people who dont have a key yet:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6

for people interested, bugs to get repoman extended to make the gpg
process smoother:
http://bugs.gentoo.org/360459
http://bugs.gentoo.org/360461
-mike

Re: [gentoo-dev] Re: rejecting unsigned commits

[Kumba]

On 03/25/2011 14:30, Mike Frysinger wrote:
> for people who dont have a key yet:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6
>
> for people interested, bugs to get repoman extended to make the gpg
> process smoother:
> http://bugs.gentoo.org/360459
> http://bugs.gentoo.org/360461
> -mike

So I'm one of those that became a dev before GPG keys were required (I think). 
at some point, though, I created one on an old machine I had, which was my 
primary dev machine at the time.  But the machine died, and I never got the key 
off (I never used it).  The drive is still good, but it's lost in a pile of 
boxes somewhere.

Rather than mounting an expedition to find it, it's probably easier for me to 
generate a new key, but this raises a few questions, because I'm a complete 
idiot when it comes to GPG/PGP stuff:

1. How can I revoke the old key?  The revocation cert is probably on the same drive.

2. The dev manual states not to create a key with an expiration longer than 6 
months.  How does this impact items signed already if the key has to be replaced 
bi-annually? (I suspect I'm not fully grasping something here w/r to GPG).

3. If I'm going to start using GPG, I might as well use it for a few things. 
Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Re: rejecting unsigned commits

[Rich Freeman]

On Sun, Mar 27, 2011 at 10:47 PM, Kumba <kumba@gentoo.org> wrote:
> 1. How can I revoke the old key?  The revocation cert is probably on the
> same drive.

You can't.  You need the private key to generate a revocation
certificate.  The best you might be able to do is ask keyserver admins
to remove it manually, or try to recover the key.

Or crack RSA...  :)

This is one of the reasons PKI is painful.

>
> 2. The dev manual states not to create a key with an expiration longer than
> 6 months.  How does this impact items signed already if the key has to be
> replaced bi-annually? (I suspect I'm not fully grasping something here w/r
> to GPG).

When gpg verifies signatures it takes into account the date the
signature was performed.  So, after this date the key is not valid for
new signatures.

Expiration dates are more about receiving encrypted data than sending
it.  Basically it tells people who have your public key to please be
nice and not use this key after this date, that way I don't need to
keep a copy of old keys until the end of time just in case.  In your
case, when your old key expires you will no longer need to worry about
getting an encrypted email you can't read.

They provide no security for stolen keys, since the date can be
changed if you have access to the private key.  This is in contrast to
SSL certificates, where the CA key would be needed to do this.  With
SSL the expiry is more about the CA than the key itself.  The only
security mechanism for stolen certs is revocation.

>
> 3. If I'm going to start using GPG, I might as well use it for a few things.
> Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows?

Enigmail.  Haven't actually used it on windows but it is pretty
transparent and I believe it supports windows.  No graceful solution
to keyring management that I know of, except that the same files
should work on both platforms, and either platform can merge two
keyring files which should make syncs easy (you're generally only
adding to them all the time).

Rich

Re: [gentoo-dev] Re: rejecting unsigned commits

[Eray Aslan]

On 2011-03-28 2:54 PM, Rich Freeman wrote:
>> 3. If I'm going to start using GPG, I might as well use it for a few things.
>> Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows?
> 
> Enigmail.  Haven't actually used it on windows but it is pretty
> transparent and I believe it supports windows.  

Aye, enigmail and thunderbird works on windows.  And gpg4win if you have
to use outlook and/or claws.

> No graceful solution
> to keyring management that I know of

WinPT is our preferred solution on windows.

-- 
Eray Aslan
Developer, Gentoo Linux       eras <at> gentoo.org

Re: [gentoo-dev] Re: rejecting unsigned commits

[Kumba]

On 03/27/2011 22:47, Kumba wrote:
> Rather than mounting an expedition to find it, it's probably easier for me to
> generate a new key, but this raises a few questions, because I'm a complete
> idiot when it comes to GPG/PGP stuff:

This is all fixed.  My new key is published, but the old one will remain on the
key servers until I can hunt down the drive w/ the old revocation cert.

Will have to play with manifest signing next time I update mips-sources...

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Re: rejecting unsigned commits

[Jim Ramsay]

On Fri, Mar 25, 2011 at 02:30:20PM -0400, Mike Frysinger wrote:
> for people who dont have a key yet:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6

I'm pretty new to advanced gpg usage and management, and so had a
couple questions not answered by that page:

- Does this tree signing key have to be DSA?  Or is RSA okay too?

- If I have a key already, should I generate a new subkey just
  for manifest signing, make a whole new primary key, or just use
  the same key I use to sign my emails?

-- 
Jim Ramsay

Re: [gentoo-dev] Re: rejecting unsigned commits

["Paweł Hajdan, Jr."]

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

On 5/10/11 4:08 AM, Jim Ramsay wrote:
> - Does this tree signing key have to be DSA?  Or is RSA okay too?

No idea, I'd probably just try and see if signing works.

> - If I have a key already, should I generate a new subkey just
>   for manifest signing, make a whole new primary key, or just use
>   the same key I use to sign my emails?

See
<http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml>,
I think no separate key should be needed.


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

Re: [gentoo-dev] Re: rejecting unsigned commits

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/10/11 02:19, "Paweł Hajdan, Jr." wrote:
> On 5/10/11 4:08 AM, Jim Ramsay wrote:
>> - Does this tree signing key have to be DSA?  Or is RSA okay too?
> 
> No idea, I'd probably just try and see if signing works.
> 
>> - If I have a key already, should I generate a new subkey just
>>   for manifest signing, make a whole new primary key, or just use
>>   the same key I use to sign my emails?
> 
> See
> <http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml>,
> I think no separate key should be needed.
> 

RSA2048 or so is > DSA in my opinion.
Just my 2 cents.

Regards,
- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- QA / Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNyTjnAAoJEEsurZwMLhUxzkoP/21ZvCkM08fkO8Glv1r9jWi2
4+UkYALoBWWvTase5BMxuarliZOiEjxHYStJ9wwY3HAt0GPLpa4HS5SJBgb0VAhd
k1khQGLY3mufUpKCmYsad85guAeir5OETemx5cfNCuUUsCcBlFotoo4CQsRTDTmq
LAMNPTvXXAdrDzek03q0b6pTiBFEl+5hPQNiyY/VdYOR6/Pmd9qGUS0Cwp1FN9BL
oayRh2ngCnu+ebd14cGIGw1OSW/9/7HpnDsg/qDiMFE0ViImWQRCzoYifzUj531K
OyG/wA90N9H6fmNXf37v7UzFrZwz42W5rgpbErfAwlcank9/4WyCOHXaMR2KmQE+
7SjlFy6gy7w1MHNI+d/pzSbpyRdmBdtJ21UD3WxT+kofVoGJ8TRTIHAdrjx+QECC
5JBQDUGzy6b352DHQb2bZcrlESIteeqt6j+XAsMHW/fhaTmXMGq9gDNB+hfdPwYl
Uun7ZVr2gUKgpIYXIp+OAvb7VTZlhKQldFtvDuiDYOr/ZdcAk6gGXc252E9N0cHm
IQysE1ANAFZ+tDvFcfOt2M/SIxzaReXuwyCgdzfaFzxCP0JMG+KYLTUqRqHi0xLK
pNL09gP0DcENRV+9l+x3h1lbZUULoKCnG/jst6n7drW0/m96YJgPvuGodG84hs3Y
pQxG4e8XW5Vw6pAlJiir
=T+gW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: rejecting unsigned commits

[Jim Ramsay]

On Tue, May 10, 2011 at 08:19:27AM +0200, "Paweł Hajdan, Jr." wrote:
> On 5/10/11 4:08 AM, Jim Ramsay wrote:
> > - Does this tree signing key have to be DSA?  Or is RSA okay too?
> 
> No idea, I'd probably just try and see if signing works.

/me plugs his ears and presses "GO"...

Looks like it works fine!

> > - If I have a key already, should I generate a new subkey just
> >   for manifest signing, make a whole new primary key, or just use
> >   the same key I use to sign my emails?
> 
> See
> <http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml>,
> I think no separate key should be needed.

You know, I even remember reading this email, but focused more on
the SSL Cert recommendation part than immediate answer.  Thanks :)

-- 
Jim Ramsay

Re: [gentoo-dev] rejecting unsigned commits

[Jeremy Olexa]

On 03/24/2011 04:59 PM, Mike Frysinger wrote:

> this is especially important for the people doing arch keywording
> since they make a ton of commits.  i'm looking at you armin76.

One thing I don't get amidst this whole conversation is why I should 
sign a Manifest file when committing KEYWORDS or something equally as 
trivial like deleting ebuilds. By signing the Manifest, I interpret that 
as "yes, I committed this Manifest file and yes I trust every hash in 
this Manifest file" when in reality, I have no clue if the Manifest file 
is correct because I didn't inspect anything.

Am I missing something?

Thanks,
Jeremy

Re: [gentoo-dev] rejecting unsigned commits

[Philipp Riegger]

On Sun, 27 Mar 2011 17:04:56 -0500
Jeremy Olexa <darkside@gentoo.org> wrote:

> > this is especially important for the people doing arch keywording
> > since they make a ton of commits.  i'm looking at you armin76.  
> 
> One thing I don't get amidst this whole conversation is why I should 
> sign a Manifest file when committing KEYWORDS or something equally as 
> trivial like deleting ebuilds. By signing the Manifest, I interpret
> that as "yes, I committed this Manifest file and yes I trust every
> hash in this Manifest file" when in reality, I have no clue if the
> Manifest file is correct because I didn't inspect anything.
> 
> Am I missing something?

You sign, that you did this. More or less. The guy before you did the
same. If there is an error all previous revisions of the tree are
available and you can check, whose mistake it was. Nothing really
changes, but I can check whether a gentoo dev committed the change and
who it was (and that it was not anybody who hacked some rsync mirror).

Philipp

--