Re: [gentoo-dev] RFC: Gentoo GPG key policies
Sorry to bother you again, but I still cannot do signed commits. I don't
know what else to try.
On Thu, 14 Mar 2013, Robin H. Johnson wrote:
On Thu, Mar 14, 2013 at 10:50:00AM +0700, gro...@gentoo.org wrote:
But my first attempt to do a signed commit has failed:
Your GPG agent is broken/missing.
These are steps I have done:
elrond ~ # eselect pinentry list
Available pinentry binary implementations:
[1] pinentry-gtk-2
[2] pinentry-qt4 *
[3] pinentry-curses
In /etc/kde/startup/agent-startup.sh:
if [ -x /usr/bin/gpg-agent ]; then
eval $(/usr/bin/gpg-agent --daemon)
fi
In /etc/kde/shutdown/agent-shutdown.sh:
if [ -n ${GPG_AGENT_INFO} ]; then
kill $(echo ${GPG_AGENT_INFO} | cut -d':' -f 2) /dev/null 21
fi
grozin@elrond ~/.gnupg $ cat gpg-agent.conf
pinentry-program /usr/bin/pinentry-qt4
no-grab
default-cache-ttl 10
In ~/.gnupg/gpg.conf:
use-agent
Then I exited a kde session, and said startx again. Now
grozin@elrond ~ $ echo ${GPG_AGENT_INFO}
/tmp/gpg-oJuN4k/S.gpg-agent:14103:1
Looks like gpg-agent is running. Now an attempt to commit:
grozin@elrond /home/gentoo-x86/media-gfx/fotoxx $ repoman commit -m 'Fix
linking with gold (bug #462286), thanks to adrian.bass...@hotmail.co.uk'
RepoMan scours the neighborhood...
Creating Manifest for /home/gentoo-x86/media-gfx/fotoxx
Note: use --include-dev (-d) to check dependencies for 'dev' profiles
* 2 files being committed... 1 have headers that will change.
* Files with headers will cause the manifests to be changed and committed
separately.
Using commit message:
--
Fix linking with gold (bug #462286), thanks to
adrian.bass...@hotmail.co.uk
(Portage version: 2.2.0_alpha169/cvs/Linux i686, signed Manifest commit
with key 00C6DAB1!)
--
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/ChangeLog,v -- ChangeLog
new revision: 1.49; previous revision: 1.48
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/files/fotoxx-13.03.patch,v --
files/fotoxx-13.03.patch
new revision: 1.2; previous revision: 1.1
Creating Manifest for /home/gentoo-x86/media-gfx/fotoxx
gpg: no default secret key: No secret key
gpg: /home/gentoo-x86/media-gfx/fotoxx/Manifest: clearsign failed: No
secret key
!!! !!! gpg exited with '2' status
!!! Disabled FEATURES='sign'
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/Manifest,v -- Manifest
new revision: 1.50; previous revision: 1.49
Commit complete.
RepoMan sez: If everyone were like you, I'd be out of business!
grozin@elrond /home/gentoo-x86/media-gfx/fotoxx $
My understanding was that I'll be asked for the pass phrase. But this does
not happen. And I don't know what else I have to configure.
Desperate,
Andrey
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 13:37 Fri 22 Mar , gro...@gentoo.org wrote: Sorry to bother you again, but I still cannot do signed commits. I don't know what else to try. ... Creating Manifest for /home/gentoo-x86/media-gfx/fotoxx gpg: no default secret key: No secret key gpg: /home/gentoo-x86/media-gfx/fotoxx/Manifest: clearsign failed: No secret key !!! !!! gpg exited with '2' status !!! Disabled FEATURES='sign' grozin@elrond /home/gentoo-x86/media-gfx/fotoxx $ My understanding was that I'll be asked for the pass phrase. But this does not happen. And I don't know what else I have to configure. ... I'm not sure if it's related, but have you set PORTAGE_GPG_DIR and/or PORTAGE_GPG_KEY in your make.conf? I'm not familiar with the error above, but it seems that gpg cannot find your keypair or something. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpYUFnhzEhIX.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Fri, 22 Mar 2013, Panagiotis Christopoulos wrote: I'm not sure if it's related, but have you set PORTAGE_GPG_DIR and/or PORTAGE_GPG_KEY in your make.conf? Sure: PORTAGE_GPG_DIR=/home/grozin/.gnupg PORTAGE_GPG_KEY=00C6DAB1! Even if I'll be able to configer gpg-agent properly, this will solve only a small part of the problem. I always do commits from elrond.inp.nsk.su, it is in my office at Budker Institute of Nuclear Physics. When I'm in my office, I'm logged in, and there's kde session. gpg-agent should ask for my pass phrase, and things should work. OK. When I'm at home, I log in elrond via ssh. As a rule, there's still a kde session at the console (why should I start emacs, firefox, etc., again next morning?). Hence there's gpg-agent running. As far as I can understand, it will ask for my pass phrase on the switched off monitor in my locked office. Not very useful. When I'm somewhere else (in Karlsruhe, for example), elrond is always switched on, but there is no session on the console. I log in via ssh. There is no gpg-agent running. How do I commit stuff? Thanks in advance, Andrey
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Fri, Mar 22, 2013 at 4:47 AM, gro...@gentoo.org wrote: On Fri, 22 Mar 2013, Panagiotis Christopoulos wrote: I'm not sure if it's related, but have you set PORTAGE_GPG_DIR and/or PORTAGE_GPG_KEY in your make.conf? Sure: PORTAGE_GPG_DIR=/home/grozin/.gnupg PORTAGE_GPG_KEY=00C6DAB1! Even if I'll be able to configer gpg-agent properly, this will solve only a small part of the problem. I always do commits from elrond.inp.nsk.su, it is in my office at Budker Institute of Nuclear Physics. When I'm in my office, I'm logged in, and there's kde session. gpg-agent should ask for my pass phrase, and things should work. OK. When I'm at home, I log in elrond via ssh. As a rule, there's still a kde session at the console (why should I start emacs, firefox, etc., again next morning?). Hence there's gpg-agent running. As far as I can understand, it will ask for my pass phrase on the switched off monitor in my locked office. Not very useful. When I'm somewhere else (in Karlsruhe, for example), elrond is always switched on, but there is no session on the console. I log in via ssh. There is no gpg-agent running. How do I commit stuff? Thanks in advance, Andrey Have you tried using keychain at the remote location? http://www.gentoo.org/doc/en/keychain-guide.xml -- David Abbott (dabbott) Gentoo http://dev.gentoo.org/~dabbott/
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 14/03/13 04:50, gro...@gentoo.org wrote: Hello *, I've followed all the instructions successfully (I think). By the way, the following lines need a small correction: perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user perl_ldap says that attributes of type multiple cannot be modified. I had to delete these attributes and then create the new ones. But my first attempt to do a signed commit has failed: Using commit message: -- Version bump (Portage version: 2.2.0_alpha166/cvs/Linux i686, signed Manifest commit with key 00C6DAB1!) -- Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/ChangeLog,v -- ChangeLog new revision: 1.9; previous revision: 1.8 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.9.ebuild,v -- clozurecl-1.9.ebuild initial revision: 1.1 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.7.ebuild,v -- clozurecl-1.7.ebuild new revision: delete; previous revision: 1.3 Creating Manifest for /home/gentoo-x86/dev-lisp/clozurecl gpg: no default secret key: No secret key gpg: /home/gentoo-x86/dev-lisp/clozurecl/Manifest: clearsign failed: No secret key !!! !!! gpg exited with '2' status !!! Disabled FEATURES='sign' Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/Manifest,v -- Manifest new revision: 1.10; previous revision: 1.9 Commit complete. RepoMan sez: If everyone were like you, I'd be out of business! What else should I do? Either use a gpg agent or use a curses based version of pinentry. Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Please don't CC me directly, you explicitly ignored the Reply-To header that this list has. On Thu, Mar 14, 2013 at 10:50:00AM +0700, gro...@gentoo.org wrote: I've followed all the instructions successfully (I think). By the way, the following lines need a small correction: perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user gpg* attributes are multiple-instance, and have correct instructions in listing 3.3 of ldap.xml. I fixed the misleading listing 3.9, that was from when gpgkey was still single-instance. But my first attempt to do a signed commit has failed: Your GPG agent is broken/missing. zmedico/portage-dev: Maybe a good idea to check for agent sanity before trying to use it? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 03/14/2013 02:12 AM, Robin H. Johnson wrote: But my first attempt to do a signed commit has failed: Your GPG agent is broken/missing. zmedico/portage-dev: Maybe a good idea to check for agent sanity before trying to use it? Yeah, we could have it do a test signature to verify that it's working properly before it tries to commit anything. We've got this bug filed: https://bugs.gentoo.org/show_bug.cgi?id=298605 -- Thanks, Zac
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Thu, 14 Mar 2013 08:26:04 -0700 Zac Medico zmed...@gentoo.org wrote: On 03/14/2013 02:12 AM, Robin H. Johnson wrote: But my first attempt to do a signed commit has failed: Your GPG agent is broken/missing. zmedico/portage-dev: Maybe a good idea to check for agent sanity before trying to use it? Yeah, we could have it do a test signature to verify that it's working properly before it tries to commit anything. We've got this bug filed: https://bugs.gentoo.org/show_bug.cgi?id=298605 If that means doing an additional signature every time something is going to be committed, that sounds like an overkill. If we were to do something radical, I'd rather be in favor of disabling keyword expansion completely and finally being able to do sane commits. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 03/14/2013 09:14 AM, Michał Górny wrote: On Thu, 14 Mar 2013 08:26:04 -0700 Zac Medico zmed...@gentoo.org wrote: On 03/14/2013 02:12 AM, Robin H. Johnson wrote: But my first attempt to do a signed commit has failed: Your GPG agent is broken/missing. zmedico/portage-dev: Maybe a good idea to check for agent sanity before trying to use it? Yeah, we could have it do a test signature to verify that it's working properly before it tries to commit anything. We've got this bug filed: https://bugs.gentoo.org/show_bug.cgi?id=298605 If that means doing an additional signature every time something is going to be committed, that sounds like an overkill. If we were to do something radical, I'd rather be in favor of disabling keyword expansion completely and finally being able to do sane commits. We could do that if we simply add all files using the cvs -kb option. However, Fabian has requested that we keep the keywords for the purposes of his prefix tree merging script: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg55238.html -- Thanks, Zac
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Thu, Mar 14, 2013 at 09:30:19AM -0700, Zac Medico wrote: We could do that if we simply add all files using the cvs -kb option. However, Fabian has requested that we keep the keywords for the purposes of his prefix tree merging script: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg55238.html With git, all keywords except $Id$ are going away. We will also be using thin Manifests, so it will only be a single-pass commit. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Thu, Mar 14, 2013 at 05:14:15PM +0100, Michał Górny wrote: If that means doing an additional signature every time something is going to be committed, that sounds like an overkill. If we were to do something radical, I'd rather be in favor of disabling keyword expansion completely and finally being able to do sane commits. I foresee it as more of: IFF this commit will call GPG later, ensure the agent can access the secret key BEFORE trying to sign at the end. As to how to accomplish this, it's either a throwaway sig, or poking the agent protocol directly. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 03/14/2013 09:01 PM, Robin H. Johnson wrote: On Thu, Mar 14, 2013 at 05:14:15PM +0100, Michał Górny wrote: If that means doing an additional signature every time something is going to be committed, that sounds like an overkill. If we were to do something radical, I'd rather be in favor of disabling keyword expansion completely and finally being able to do sane commits. I foresee it as more of: IFF this commit will call GPG later, ensure the agent can access the secret key BEFORE trying to sign at the end. As to how to accomplish this, it's either a throwaway sig, or poking the agent protocol directly. The only trouble with that is if the agent is configured to only unlock keys for limited periods of time, then your initial check might catch the agent when the key is still unlocked, but your subsequent call to GPG comes after the timeout. I ran into this while trying to set up automated signing of debian packages I was building. All it really means, in a practical procedural sense, is that you need to allow yourself a way to roll back anything you've been doing if that later check fails. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Thu, Mar 14, 2013 at 10:32:30PM -0400, Michael Mol wrote: As to how to accomplish this, it's either a throwaway sig, or poking the agent protocol directly. The only trouble with that is if the agent is configured to only unlock keys for limited periods of time, then your initial check might catch the agent when the key is still unlocked, but your subsequent call to GPG comes after the timeout. I ran into this while trying to set up automated signing of debian packages I was building. So Debian has a test-gpg function already? Do you know where in their codebase it is? All it really means, in a practical procedural sense, is that you need to allow yourself a way to roll back anything you've been doing if that later check fails. I think we'd do: - All repoman checks - initial file editing if two-phase commit: - test gpg - commit1 - gpg sign - commit2 if one-phase commit: - gpg test - gpg sign - commit1 Unless commit1 took a really long time, the interval between the gpg calls should be very small. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 03/14/2013 11:18 PM, Robin H. Johnson wrote: On Thu, Mar 14, 2013 at 10:32:30PM -0400, Michael Mol wrote: As to how to accomplish this, it's either a throwaway sig, or poking the agent protocol directly. The only trouble with that is if the agent is configured to only unlock keys for limited periods of time, then your initial check might catch the agent when the key is still unlocked, but your subsequent call to GPG comes after the timeout. I ran into this while trying to set up automated signing of debian packages I was building. So Debian has a test-gpg function already? Do you know where in their codebase it is? No idea; a build system I'd cobbled together at the time prodded gpg-agent to get an interactive auth. The build-and-package step took too long, leading to the timeout. And I apologize; I don't remember exactly what I was doing to prod gpg-agent, and since it was for a prior job, I did not retain any copies of any of the materials. All it really means, in a practical procedural sense, is that you need to allow yourself a way to roll back anything you've been doing if that later check fails. I think we'd do: - All repoman checks - initial file editing if two-phase commit: - test gpg - commit1 - gpg sign - commit2 if one-phase commit: - gpg test - gpg sign - commit1 Unless commit1 took a really long time, the interval between the gpg calls should be very small. Murphy's going to call in a long I/O hang somewhere. Race conditions are hell manifest in systems. Since I haven't been paying close attention to this thread, I'm missing some context, but if you're commit1 and commit2 apply to a DVCS, you're probably fine so long as you don't do a push between commit1 and commit2, don't do a push if any earlier step failed, and do all this in a temporary branch that never (as a branch) gets pushed upstream. If you're not applying to a DVCS, then you risk interleaving commit1 and commit2 with others' work anyway. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Fri, 15 Mar 2013 03:18:18 + Robin H. Johnson robb...@gentoo.org wrote: if one-phase commit: - gpg test - gpg sign - commit1 Why do we need additional 'gpg test' here? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Fri, Mar 15, 2013 at 05:44:20AM +0100, Michał Górny wrote: On Fri, 15 Mar 2013 03:18:18 + Robin H. Johnson robb...@gentoo.org wrote: if one-phase commit: - gpg test - gpg sign - commit1 Why do we need additional 'gpg test' here? In the case of git commit signing, repoman is not directly invoking gpg. Rather GPG is being invoked by Git, and we are much more limited in our ability to catch a GPG error. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Thu, Mar 14, 2013 at 11:33:36PM -0400, Michael Mol wrote: So Debian has a test-gpg function already? Do you know where in their codebase it is? No idea; a build system I'd cobbled together at the time prodded gpg-agent to get an interactive auth. The build-and-package step took too long, leading to the timeout. And I apologize; I don't remember exactly what I was doing to prod gpg-agent, and since it was for a prior job, I did not retain any copies of any of the materials. Aww, thanks anyway. If you're not applying to a DVCS, then you risk interleaving commit1 and commit2 with others' work anyway. two-phase commit is only where the files in the Manifest will change after they are committed. commit1 = files + Manifest commit2 = files w/ changed keywords + Manifest This is how our existing CVS commits work already. If you don't have keywords, or you use thin-Manifest, you only ever need one-phase commit. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Hello *, I've followed all the instructions successfully (I think). By the way, the following lines need a small correction: perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user perl_ldap says that attributes of type multiple cannot be modified. I had to delete these attributes and then create the new ones. But my first attempt to do a signed commit has failed: Using commit message: -- Version bump (Portage version: 2.2.0_alpha166/cvs/Linux i686, signed Manifest commit with key 00C6DAB1!) -- Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/ChangeLog,v -- ChangeLog new revision: 1.9; previous revision: 1.8 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.9.ebuild,v -- clozurecl-1.9.ebuild initial revision: 1.1 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.7.ebuild,v -- clozurecl-1.7.ebuild new revision: delete; previous revision: 1.3 Creating Manifest for /home/gentoo-x86/dev-lisp/clozurecl gpg: no default secret key: No secret key gpg: /home/gentoo-x86/dev-lisp/clozurecl/Manifest: clearsign failed: No secret key !!! !!! gpg exited with '2' status !!! Disabled FEATURES='sign' Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/Manifest,v -- Manifest new revision: 1.10; previous revision: 1.9 Commit complete. RepoMan sez: If everyone were like you, I'd be out of business! What else should I do? Andrey
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT) gro...@gentoo.org wrote: Hello *, I am stuck and have many questions. [In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.] 1. So, I start gpg --gen-key It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later? Editing the conf should be done first, some of the preferences (e.g. personal-digest-preference and cert-digest-algo) affect the creation of keys. 2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address. After that, gpg --list-keys says /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] So, my key id is 0x16_hex_digits_1, right? Yep, but why did you bother to replace the information? 3. Now I do gpg --edit-key 0x16_hex_digits_1 addkey Then I choose (4) RSA (sign only) right? Then I choose 4096, 1y, y, y, save. Now gpg --list-keys gives /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] sub 4096R/0x16_hex_digits_3 2013-02-26 [expires: 2014-02-26] 4. I do gpg --output revoke.asc --gen-revoke 0x16_hex_digits_1 and choose 1. That's all correct. 6. Encrypted backup of your secret keys. I don't understand this. It'd make sense to have an backup of your keys (~/.gnupg/secring.gpg) stored in a safe place, just as with everything else... If you want, you can protect it by another layer of encryption, but it's not that important, because the keys are already protected by your passphrase. 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g I don't understand this. Neither do I (I know what it does, but I don't see what it's good for) – just leave it out, it's not necessary. 5. I do gpg --keyserver subkeys.pgp.net --send-key 0x16_hex_digits_1 6. On dev.gentoo.org, I am supposed to do perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user Is gpg-id 0x16_hex_digits_1? Or 0x16_hex_digits_3? What is gpg-fingerprint and how do I get it? Is user my username on dev.gentoo.org? What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password? I can't help you with that, as I don't have access to any gentoo infrastructure. But IIRC, that's the password you once set on d.g.o with passwd. 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and PORTAGE_GPG_DIR=/home/username/.gnupg and also PORTAGE_GPG_KEY=0x16_hex_digits_3! Is this correct? Is it 16_hex_digits_3, and not, say, 16_hex_digits_1? Should I add ! at the end, as suggested by mgorny? 16_hex_digits_3 (the one you added later via addkey) is the correct one. And adding a ! is absolutely necessary. During the time I'm reading all these instructions, I could bump 10 packages. Very complicated for a person who does not use gpg and knows next to nothing about it. Security can be hard to grasp at times. Sadly... HTH, Luis signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Thanks for the partial response Luis. On Wed, Feb 27, 2013 at 04:12:14PM +0100, Luis Ressel wrote: On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT) gro...@gentoo.org wrote: Hello *, I am stuck and have many questions. New addition to the instructions: 0. Copy /usr/share/gnupg/gpg-conf.skel to ~/.gnupg/gpg.conf, append the block given in my email. TODO: The upstream skeleton config file has improved over the years, it would be useful for all users to get updates to it, but etc-update only works for /etc, since this is deployed per-user. Suggestions welcome on getting users to do this. [In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.] 1. So, I start gpg --gen-key It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later? Editing the conf should be done first, some of the preferences (e.g. personal-digest-preference and cert-digest-algo) affect the creation of keys. See step 0 above, and do gen-key AFTER that. 3. Now I do gpg --edit-key 0x16_hex_digits_1 addkey Then I choose (4) RSA (sign only) right? Then I choose 4096, 1y, y, y, save. Now gpg --list-keys gives /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] sub 4096R/0x16_hex_digits_3 2013-02-26 [expires: 2014-02-26] 4. I do gpg --output revoke.asc --gen-revoke 0x16_hex_digits_1 and choose 1. That's all correct. Make sure to put that revoke.asc file in a secure place, and REMOVE the unprotected copy from your system. It has NO encryption on that file, by design. 6. Encrypted backup of your secret keys. I don't understand this. It'd make sense to have an backup of your keys (~/.gnupg/secring.gpg) stored in a safe place, just as with everything else... If you want, you can protect it by another layer of encryption, but it's not that important, because the keys are already protected by your passphrase. Yes, your normal keys are protected by your passphrase. If you have additional SEPARATE keys that might not have passphrases (eg for automation purposes), having them encrypted on your backup media is a good idea. If you don't have any other keys like that, I've attached a backup script for you to use (originally written because some versions ago there was a gnupg locking bug, and it would occasionally corrupt/overwrite my public keyring). 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g I don't understand this. Neither do I (I know what it does, but I don't see what it's good for) – just leave it out, it's not necessary. Here's the origin of this: http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html Basically, just like the rest of the expansion to use full length keyids to avoid collision attacks, this does the same for certifications. 5. I do gpg --keyserver subkeys.pgp.net --send-key 0x16_hex_digits_1 6. On dev.gentoo.org, I am supposed to do perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user Is gpg-id 0x16_hex_digits_1? Or 0x16_hex_digits_3? What is gpg-fingerprint and how do I get it? Is user my username on dev.gentoo.org? What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password? I can't help you with that, as I don't have access to any gentoo infrastructure. But IIRC, that's the password you once set on d.g.o with passwd. Your recruiter should have pointed you to your LDAP password when you become a developer for new developers. In case of old developers, this wasn't reliable followed, and/or gets lost. Please contact infra or the devrel leads to get your LDAP password reset. 'user' is your Gentoo developer username. Be careful to NOT replace the '-b user' part, that selects 'user' mode for the tool. 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and PORTAGE_GPG_DIR=/home/username/.gnupg and also PORTAGE_GPG_KEY=0x16_hex_digits_3! Is this correct? Is it 16_hex_digits_3, and not, say, 16_hex_digits_1? Should I add ! at the end, as suggested by mgorny? 16_hex_digits_3 (the one you added later via addkey) is the
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 27, 2013 at 11:04 AM, Robin H. Johnson robb...@gentoo.org wrote: Thanks for the partial response Luis. On Wed, Feb 27, 2013 at 04:12:14PM +0100, Luis Ressel wrote: On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT) gro...@gentoo.org wrote: Hello *, I am stuck and have many questions. New addition to the instructions: 0. Copy /usr/share/gnupg/gpg-conf.skel to ~/.gnupg/gpg.conf, append the block given in my email. TODO: The upstream skeleton config file has improved over the years, it would be useful for all users to get updates to it, but etc-update only works for /etc, since this is deployed per-user. Suggestions welcome on getting users to do this. [In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.] 1. So, I start gpg --gen-key It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later? Editing the conf should be done first, some of the preferences (e.g. personal-digest-preference and cert-digest-algo) affect the creation of keys. See step 0 above, and do gen-key AFTER that. 3. Now I do gpg --edit-key 0x16_hex_digits_1 addkey Then I choose (4) RSA (sign only) right? Then I choose 4096, 1y, y, y, save. Now gpg --list-keys gives /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] sub 4096R/0x16_hex_digits_3 2013-02-26 [expires: 2014-02-26] 4. I do gpg --output revoke.asc --gen-revoke 0x16_hex_digits_1 and choose 1. That's all correct. Make sure to put that revoke.asc file in a secure place, and REMOVE the unprotected copy from your system. It has NO encryption on that file, by design. 6. Encrypted backup of your secret keys. I don't understand this. It'd make sense to have an backup of your keys (~/.gnupg/secring.gpg) stored in a safe place, just as with everything else... If you want, you can protect it by another layer of encryption, but it's not that important, because the keys are already protected by your passphrase. Yes, your normal keys are protected by your passphrase. If you have additional SEPARATE keys that might not have passphrases (eg for automation purposes), having them encrypted on your backup media is a good idea. If you don't have any other keys like that, I've attached a backup script for you to use (originally written because some versions ago there was a gnupg locking bug, and it would occasionally corrupt/overwrite my public keyring). 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g I don't understand this. Neither do I (I know what it does, but I don't see what it's good for) – just leave it out, it's not necessary. Here's the origin of this: http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html Basically, just like the rest of the expansion to use full length keyids to avoid collision attacks, this does the same for certifications. 5. I do gpg --keyserver subkeys.pgp.net --send-key 0x16_hex_digits_1 6. On dev.gentoo.org, I am supposed to do perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user Is gpg-id 0x16_hex_digits_1? Or 0x16_hex_digits_3? What is gpg-fingerprint and how do I get it? Is user my username on dev.gentoo.org? What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password? I can't help you with that, as I don't have access to any gentoo infrastructure. But IIRC, that's the password you once set on d.g.o with passwd. Your recruiter should have pointed you to your LDAP password when you become a developer for new developers. In case of old developers, this wasn't reliable followed, and/or gets lost. Please contact infra or the devrel leads to get your LDAP password reset. 'user' is your Gentoo developer username. Be careful to NOT replace the '-b user' part, that selects 'user' mode for the tool. FYI: I patched perl_ldap so this doesn't happen, as it was a very common mistake. -A 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and PORTAGE_GPG_DIR=/home/username/.gnupg and also
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Hello *, I am stuck and have many questions. [In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.] 1. So, I start gpg --gen-key It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later? 2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address. After that, gpg --list-keys says /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] So, my key id is 0x16_hex_digits_1, right? 3. Now I do gpg --edit-key 0x16_hex_digits_1 addkey Then I choose (4) RSA (sign only) right? Then I choose 4096, 1y, y, y, save. Now gpg --list-keys gives /home/username/.gnupg/pubring.gpg --- pub 4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26] uid [ultimate] my_name my_gentoo_email_address sub 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26] sub 4096R/0x16_hex_digits_3 2013-02-26 [expires: 2014-02-26] 4. I do gpg --output revoke.asc --gen-revoke 0x16_hex_digits_1 and choose 1. 6. Encrypted backup of your secret keys. I don't understand this. 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g I don't understand this. 5. I do gpg --keyserver subkeys.pgp.net --send-key 0x16_hex_digits_1 6. On dev.gentoo.org, I am supposed to do perl_ldap -b user -M gpgkey gpg-id user perl_ldap -b user -M gpgfingerprint gpg-fingerprint user Is gpg-id 0x16_hex_digits_1? Or 0x16_hex_digits_3? What is gpg-fingerprint and how do I get it? Is user my username on dev.gentoo.org? What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password? 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and PORTAGE_GPG_DIR=/home/username/.gnupg and also PORTAGE_GPG_KEY=0x16_hex_digits_3! Is this correct? Is it 16_hex_digits_3, and not, say, 16_hex_digits_1? Should I add ! at the end, as suggested by mgorny? During the time I'm reading all these instructions, I could bump 10 packages. Very complicated for a person who does not use gpg and knows next to nothing about it. Andrey Grozin
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, 18 Feb 2013 23:27:46 + Robin H. Johnson robb...@gentoo.org wrote: Recommendations: 3. Dedicated Gentoo signing subkey of EITHER: 3.1. DSA 2048 bits 3.2. RSA 4096 bits As a note for those who didn't know this; to make gpg use the dedicated subkey, you need to append an exclamation mark (!) to it. Like: PORTAGE_GPG_KEY=9627F456F9DA7643! Otherwise, GPG will just use this as a reference to the whole key, and may use other subkey. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 21 February 2013 09:09, Michał Górny mgo...@gentoo.org wrote: On Mon, 18 Feb 2013 23:27:46 + Robin H. Johnson robb...@gentoo.org wrote: Recommendations: 3. Dedicated Gentoo signing subkey of EITHER: 3.1. DSA 2048 bits 3.2. RSA 4096 bits As a note for those who didn't know this; to make gpg use the dedicated subkey, you need to append an exclamation mark (!) to it. Like: PORTAGE_GPG_KEY=9627F456F9DA7643! Otherwise, GPG will just use this as a reference to the whole key, and may use other subkey. -- Best regards, Michał Górny Thanks for that. I didn't know it and I couldn't find any references in the manpages. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, Feb 19, 2013 at 10:32:13PM -0800, Alec Warner wrote: I agree that a smartcard is much better security vs a longer key. I don't think attackers targetting Gentoo are going to brute force the key. They are going to steal the key, trivially, by exploiting a 0-day in a crappy browser, or flash, or java, or whatever. A smartcard is the defense against this attack (because the key material is well protected, and they need physical access to actually relocate it.) Storing it in the TPM would also be cool, except TPMs are crap on Linux, *and* most hardware TPMs are crap anyway. Exactly. The longer key doesn't block this attack, the smartcard does. The question being asked becomes: If the smartcard only supports a shorter key is that an acceptable tradeoff where a longer key would be used instead? I say it's a very acceptable tradeoff, and the require/recommend of the proposal reflects this. Also, if there is a Well-Funded-Organization attacking Gentoo, there are MUCH more effective ways for them to compromise us. Any perceived gains in that field from requiring DSA2048 and blocking DSA1024 should be examined very closely. I would ask the opposite question. What is the perceived difficulty in using DSA2048 vs 1024? For the non-smartcard users, the cost is likely trivial. Even your perf data shows that signing requests still complete in 200ms or less, and that is on old / slow hardware. This is why I recommended DSA2048, but only required DSA1024. I don't want something that says If you use a smartcard, you can use DSA1024, otherwise you must use DSA2048 That's just too confusing. djm works for Google, and I chat with him at least once a quarter. I've seen some patches go by that we could re-purpose for gpg-agent forwarding. For slow machines we could have them sign on a faster-trusted machine with a forwarded agent. Major +1 on gpg-agent forwarding request; the smartcard crowd would love it too. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
RHJ == Robin H Johnson robb...@gentoo.org writes: RHJ 2. Root key type of RSA, 4096 bits rsa 4k provides no real benefits over rsa 3k here; it is just slower for everyone, signing or verifying. Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which recommends rsa 3k for use with aes128/sha256, rsa 7k for aes192/sha384 and rsa 15k for aes256/sha512. If 3k provides comparable security to aes128 and sha256, and one needs to more than double the rsa key length to compare with aes192 and sha384, there is no reason to bother with rsa 4k. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 01:41:03PM -0500, James Cloos wrote: RHJ == Robin H Johnson robb...@gentoo.org writes: RHJ 2. Root key type of RSA, 4096 bits rsa 4k provides no real benefits over rsa 3k here; it is just slower for everyone, signing or verifying. You can shorten the subkeys, but the root key should ONLY be used for certifications key operations, not signing of external objects. The subkeys should be used for the external objects, and that's where you'd shorten if you really wanted. However, I'd suggest you not bother. Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which recommends rsa 3k for use with aes128/sha256, rsa 7k for aes192/sha384 and rsa 15k for aes256/sha512. If 3k provides comparable security to aes128 and sha256, and one needs to more than double the rsa key length to compare with aes192 and sha384, there is no reason to bother with rsa 4k. Speed for i7-2600K CPU: DSA1024 0.007980s DSA2048 0.011940s DSA3072 0.013530s RSA1024 0.007000s RSA2048 0.012290s RSA3072 0.018420s RSA4096 0.030800s 30ms is still an acceptable signing time - not noticeably different than RSA2048/RSA3072. Better question to all of this, is there somebody with a PGP smartcard that can do the same tests? I'll provide some scripts for the testcase itself, but you'll have to see about generating a bunch of keys on the smartcard, which might be problematic. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Am Mittwoch, 20. Februar 2013, 20:36:22 schrieb Robin H. Johnson: Speed for i7-2600K CPU: DSA1024 0.007980s DSA2048 0.011940s DSA3072 0.013530s RSA1024 0.007000s RSA2048 0.012290s RSA3072 0.018420s RSA4096 0.030800s Which of course brings up the question, why the hardcoded 4096 limit in GnuPG... but I guess that's not our problem yet. https://www.google.de/search?q=gnupg+rsa+8192 -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, 18 Feb 2013 23:27:46 + Robin H. Johnson robb...@gentoo.org wrote: 3. Dedicated Gentoo signing subkey What's the point of this, btw? Luis signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 09:22:05PM +0100, Andreas K. Huettel wrote: Which of course brings up the question, why the hardcoded 4096 limit in GnuPG... but I guess that's not our problem yet. https://www.google.de/search?q=gnupg+rsa+8192 Standards interoperability. RSA4096 will not work on legacy PGP implementations key servers. The next release of the OpenPGP spec is supposed to raise this. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 09:38:38PM +0100, Luis Ressel wrote: On Mon, 18 Feb 2013 23:27:46 + Robin H. Johnson robb...@gentoo.org wrote: 3. Dedicated Gentoo signing subkey What's the point of this, btw? Ideally keeping your primary key offline to increase security. However, the original theory was that if there was some attack that required a large amount of ciphertext or a targeted plaintext input, you would be limiting the ciphertext to only gentoo-specific content, and could trivially rotate the subkey without any impact on your primary key. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, 20 Feb 2013 21:37:38 + Robin H. Johnson robb...@gentoo.org wrote: Ideally keeping your primary key offline to increase security. However, the original theory was that if there was some attack that required a large amount of ciphertext or a targeted plaintext input, you would be limiting the ciphertext to only gentoo-specific content, and could trivially rotate the subkey without any impact on your primary key. I totally agree with the idea of having a separate subkey for signing purposes, but look at my key, for example: I already have a separate subkey for signing, the primary key is only used for certifications (and is actually kept offline ;). If I was a Gentoo dev, it wouldn't seem that logical to have to create yet another signing subkey. Therefore, I'd propose to remove the Gentoo part from Dedicated Gentoo signing subkey. Luis signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, Feb 18, 2013 at 11:38 PM, Kent Fredric kentfred...@gmail.com wrote: The key rotation as described in RiseUp best practices should be a very rare occurrence. Each dev is going to run it at most once. Some material I read recommended doing a key rotation every 6 months, which I did for a while until it got tiresome to perform the rotation. It turns out that real security is very inconvenient ;) I believe the rationale behind it was basically, the longer you use a key, and the more data you produce signed by a key, the more leverage an attacker has against you to compromise the key. But I have no idea if that is really relevant or not. Trust is not really conferred by 'how much you have signed with the key.' It is conferred by 'how many people trust your key.' It is unclear to me how difficult this is to calculate in practice for an attacker. You rotate keys nominally because during routine key handling, your key (unless it is stored in a smartcard) is exposed to risk during use (the key material is mlocked in memory, or they can chat with your gpg-agent to sign content, or try to steal the key material, or steal the passphrase, and so forth.) If someone got your key, they can only sign data with it for $INTERVAL until it expires and you generate a new key. The attacker has no incentive to renew the key for you, because that would expose him, as he has to publish the renewal. All of this is similar in scope to changing your password every $INTERVAL, which is standard security practice. Generally speaking if the attacker is running code as you, or as root, on the machine that you are signing content on, you are already screwed. If the attacker has persistent access to your machine, generating a new key does not help at all (he will get that one too.) A common guard against this is simply to perform host attestation. I don't think that is in scope for Gentoo though :) -A -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] RFC: Gentoo GPG key policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just some quick thoughts on this: 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits I don't really agree. From your own link (https://we.riseup.net/riseuplabs+paow/openpgp-best-practices#dont-use-pgp-mit-edu): Many people still have 1024-bit DSA keys. You really should consider transitioning to a stronger bit-length and hashing algo. This size is known now to be within Well Funded Organizations’ ability to break. Also the hashing algo is showing its age. Some more opinions from different studies: keylength.com. 1024 DSA keys seem pretty short to me. Surely it might be inconvenient for some (2-3? please write a mail here!) people with smart cards. But then again, especially people going through the hell of using a physical token would understand the need for decent crypto. ;) I think key rotation is overdoing it and pretty annoying. Better use a non-annoying, long key from the start? 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. How slow is that actually? Does it make signing very inconvenient? Maybe someone with a slow machine can write about performance and the annoyence-factor... ;) Best regards, Craig -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEkGjEACgkQuiczp+KMe7SkWACgrioKjFkuPwJOxUCmhGKcC4Ib uyQAmwUfM7u3x6sD1rmQJrEjjUu7C6ok =OyqH -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 01:34:57AM +0100, Stefan Behte wrote: 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits ... 1024 DSA keys seem pretty short to me. Surely it might be inconvenient for some (2-3? please write a mail here!) people with smart cards. But then again, especially people going through the hell of using a physical token would understand the need for decent crypto. ;) A physical token defends against a different method of attack than a longer key. Simply having a longer key isn't going to help you if store the key on the laptop and it gets compromised: presuming the attacker extracts your secret key and passphrase). In such a case, the smartcard at worst limits him to doing some number of signatures only, or even better if the reader has a hardwired pinpad, he gets nowhere at all. Also, if there is a Well-Funded-Organization attacking Gentoo, there are MUCH more effective ways for them to compromise us. Any perceived gains in that field from requiring DSA2048 and blocking DSA1024 should be examined very closely. I think key rotation is overdoing it and pretty annoying. Better use a non-annoying, long key from the start? NOWHERE did I require key rotation. Why do you think that I did? My own key is more than a decade old. I need to see about replacing it soon, but I've been trying to hold out for the OpenPGP standard to have ECC included, before I repeat getting my extremely large web-of-trust. 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. How slow is that actually? Does it make signing very inconvenient? Maybe someone with a slow machine can write about performance and the annoyence-factor... ;) Some benchmark results from hake.hppa.dev.g.o, 552Mhz PA-RISC box. Average of running clearsign ~100 times, for various signature types. The gpg.conf was set as in my initial post. DSA1024 0.059830s DSA2048 0.158800s DSA3072 0.274850s RSA1024 0.060020s RSA2048 0.173070s RSA4096 0.896480s For reasons of time, while I wanted to create the keys on the host as well for timing, I gave up after the first key, DSA1024, took more than 3 minutes (I did ensure that /dev/random was not the blocking factor). If somebody from MIPS or m68k wants to chime in, I think they probably have the slowest hardware around presently. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, Feb 19, 2013 at 7:12 PM, Robin H. Johnson robb...@gentoo.org wrote: On Wed, Feb 20, 2013 at 01:34:57AM +0100, Stefan Behte wrote: 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits ... 1024 DSA keys seem pretty short to me. Surely it might be inconvenient for some (2-3? please write a mail here!) people with smart cards. But then again, especially people going through the hell of using a physical token would understand the need for decent crypto. ;) A physical token defends against a different method of attack than a longer key. Simply having a longer key isn't going to help you if store the key on the laptop and it gets compromised: presuming the attacker extracts your secret key and passphrase). In such a case, the smartcard at worst limits him to doing some number of signatures only, or even better if the reader has a hardwired pinpad, he gets nowhere at all. I'm a bit confused. I agree that a smartcard is much better security vs a longer key. I don't think attackers targetting Gentoo are going to brute force the key. They are going to steal the key, trivially, by exploiting a 0-day in a crappy browser, or flash, or java, or whatever. A smartcard is the defense against this attack (because the key material is well protected, and they need physical access to actually relocate it.) Storing it in the TPM would also be cool, except TPMs are crap on Linux, *and* most hardware TPMs are crap anyway. Also, if there is a Well-Funded-Organization attacking Gentoo, there are MUCH more effective ways for them to compromise us. Any perceived gains in that field from requiring DSA2048 and blocking DSA1024 should be examined very closely. I would ask the opposite question. What is the perceived difficulty in using DSA2048 vs 1024? For the non-smartcard users, the cost is likely trivial. Even your perf data shows that signing requests still complete in 200ms or less, and that is on old / slow hardware. I think key rotation is overdoing it and pretty annoying. Better use a non-annoying, long key from the start? NOWHERE did I require key rotation. Why do you think that I did? My own key is more than a decade old. I need to see about replacing it soon, but I've been trying to hold out for the OpenPGP standard to have ECC included, before I repeat getting my extremely large web-of-trust. 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. How slow is that actually? Does it make signing very inconvenient? Maybe someone with a slow machine can write about performance and the annoyence-factor... ;) Some benchmark results from hake.hppa.dev.g.o, 552Mhz PA-RISC box. Average of running clearsign ~100 times, for various signature types. The gpg.conf was set as in my initial post. DSA1024 0.059830s DSA2048 0.158800s DSA3072 0.274850s RSA1024 0.060020s RSA2048 0.173070s RSA4096 0.896480s For reasons of time, while I wanted to create the keys on the host as well for timing, I gave up after the first key, DSA1024, took more than 3 minutes (I did ensure that /dev/random was not the blocking factor). If somebody from MIPS or m68k wants to chime in, I think they probably have the slowest hardware around presently. djm works for Google, and I chat with him at least once a quarter. I've seen some patches go by that we could re-purpose for gpg-agent forwarding. For slow machines we could have them sign on a faster-trusted machine with a forwarded agent. -A -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] RFC: Gentoo GPG key policies
Hi all, I've been asked a couple of times in IRC and other mediums, about what GPG key settings etc to use. I would not not call these final yet, but should be fairly close to final. This was originally intended to be part of the tree-signing GLEP series, but was in one of the unpublished ones (GLEPxx+3 in the references). I guess if there are no major objections to the below, I'll finalize them into the GLEP. This will replace the conflicting information in: http://devmanual.gentoo.org/general-concepts/manifest/index.html http://www.gentoo.org/doc/en/gnupg-user.xml The following is based on: - NIST SP 800-57 recommendations - Debian GPG documentation - RiseUp.net OpenPGP best practices. Bare minimum requirements: -- 1. SHA2-series output digest (SHA1 digests internally permitted). personal-digest-preferences SHA256 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits 3. Key expiry: 5 years. Recommendations: 1. SHA2-series digest on output certifications: personal-digest-preferences SHA256 cert-digest-algo SHA256 2. Root key type of RSA, 4096 bits 2.1. This may require creating an entirely new key. 3. Dedicated Gentoo signing subkey of EITHER: 3.1. DSA 2048 bits 3.2. RSA 4096 bits 4. Key expiry: 4.1. Root key: 3 year max. 4.2. Gentoo subkey: 1 year max. 5. Create a revocation certificate store it hardcopy offsite securely (it's about ~300 bytes). 6. Encrypted backup of your secret keys. 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g Notes/FAQ: -- 1. Ok, so how do I follow this? http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ http://keyring.debian.org/creating-key.html 2. How can I be really sure/paranoid enough? https://we.riseup.net/riseuplabs+paow/openpgp-best-practices 3. Every 3-6 months, and/or before key expiry and major keysigning events, you should update your key expiry date with the 'expire' command (remember to do all subkeys). Put it on your calendar! 4. If you intend to sign on a slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. 5. Can you give me a full ~/.gnupg/gpg.conf file? === # -- robbat2's recommendations: keyserver pool.sks-keyservers.net emit-version default-recipient-self # -- All of the below portion from the RiseUp.net OpenPGP best practices, and # -- many of them are also in the Debian GPG documentation. # when outputting certificates, view user IDs distinctly from keys: fixed-list-mode # long keyids are more collision-resistant than short keyids (it's trivial to make a key with any desired short keyid) keyid-format 0xlong # when multiple digests are supported by all recipients, choose the strongest one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # If you use a graphical environment (and even if you don't) you should be using an agent: # (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64) use-agent # You should always know at a glance which User IDs gpg thinks are legitimately bound to the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g # when making an OpenPGP certification, use a stronger digest than the default SHA1: cert-digest-algo SHA256 === -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, Feb 18, 2013 at 11:27:46PM +, Robin H. Johnson wrote: 2. root key signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits 2.2. RSA, =2048 bits 3. Key expiry: 5 years. Clarification on reason: These key sizes are the largest supported by many smartcards. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
It may be advantageous to have a gentoo wrapper script that calls GPG with recommended settings to make some tasks easier, gentoo-gpg-create --recommended EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF and gentoo-gpg-rotation would make a templated key-expiry document , edited in $EDITOR, and then cross-signed I may even take a stab at this myself once the GLEP is finalised, just curious what people think. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, Feb 19, 2013 at 04:36:08PM +1300, Kent Fredric wrote: It may be advantageous to have a gentoo wrapper script that calls GPG with recommended settings to make some tasks easier, gentoo-gpg-create --recommended EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF and gentoo-gpg-rotation would make a templated key-expiry document , edited in $EDITOR, and then cross-signed The key rotation as described in RiseUp best practices should be a very rare occurrence. Each dev is going to run it at most once. However, both the creation helper and an expiry update helper would be useful. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, 2013-02-19 at 04:09 +, Robin H. Johnson wrote: On Tue, Feb 19, 2013 at 04:36:08PM +1300, Kent Fredric wrote: It may be advantageous to have a gentoo wrapper script that calls GPG with recommended settings to make some tasks easier, gentoo-gpg-create --recommended EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF and gentoo-gpg-rotation would make a templated key-expiry document , edited in $EDITOR, and then cross-signed The key rotation as described in RiseUp best practices should be a very rare occurrence. Each dev is going to run it at most once. However, both the creation helper and an expiry update helper would be useful. It can be done as part of gkeys from the gentoo-keys project I've started which will be used to manage gpg keys for validating git commits, release media, layman's repositories.xml list, etc... I welcome help in coding it. http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git;a=summary http://wiki.gentoo.org/wiki/Project:Gentoo-keys Sadly, I got sidetracked, so haven't gotten much done lately. But am getting back to it again now.
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, Feb 18, 2013 at 11:27:46PM +, Robin H. Johnson wrote: Bare minimum requirements: -- [...] 3. Key expiry: 5 years. I am assuming we are requiring a maximum of 5 years for key expiry. We might want to make it explicit. On first reading, it sounded like key expiry = 5 years as a bare minimum. Thanks for the write-up. -- Eray Aslan e...@gentoo.org pgpa5Y0CBt3i2.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
The key rotation as described in RiseUp best practices should be a very rare occurrence. Each dev is going to run it at most once. Some material I read recommended doing a key rotation every 6 months, which I did for a while until it got tiresome to perform the rotation. I believe the rationale behind it was basically, the longer you use a key, and the more data you produce signed by a key, the more leverage an attacker has against you to compromise the key. But I have no idea if that is really relevant or not. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
