[gentoo-dev] RFC: Gentoo GPG key policies

[gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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-fpr@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-fpr@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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

On Mon, Feb 18, 2013 at 11:27:46PM +0000, 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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Kent Fredric]

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

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Brian Dolbec]

On Tue, 2013-02-19 at 04:09 +0000, 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

[Kent Fredric]

> 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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Alec Warner]

On Mon, Feb 18, 2013 at 11:38 PM, Kent Fredric <kentfredric@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
>

[gentoo-dev] Re: RFC: Gentoo GPG key policies

[Ryan Hill]

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

On Tue, 19 Feb 2013 16:36:08 +1300
Kent Fredric <kentfredric@gmail.com> 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
> 
> I may even take a stab at this myself once the GLEP is finalised, just
> curious what people think.

I'd use it.


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Eray Aslan]

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

On Mon, Feb 18, 2013 at 11:27:46PM +0000, 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 <eras@gentoo.org>

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Stefan Behte]

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

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Alec Warner]

On Tue, Feb 19, 2013 at 7:12 PM, Robin H. Johnson <robbat2@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     : robbat2@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[James Cloos]

>>>>> "RHJ" == Robin H Johnson <robbat2@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 <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

On Wed, Feb 20, 2013 at 01:41:03PM -0500, James Cloos wrote:
> >>>>> "RHJ" == Robin H Johnson <robbat2@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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Andreas K. Huettel]

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

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 
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] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Luis Ressel]

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

On Mon, 18 Feb 2013 23:27:46 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:


> 3. Dedicated Gentoo signing subkey

What's the point of this, btw?


Luis

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

On Wed, Feb 20, 2013 at 09:38:38PM +0100, Luis Ressel wrote:
> On Mon, 18 Feb 2013 23:27:46 +0000
> "Robin H. Johnson" <robbat2@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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Luis Ressel]

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

On Wed, 20 Feb 2013 21:37:38 +0000
"Robin H. Johnson" <robbat2@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

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Michał Górny]

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

On Mon, 18 Feb 2013 23:27:46 +0000
"Robin H. Johnson" <robbat2@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

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Markos Chandras]

On 21 February 2013 09:09, Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 18 Feb 2013 23:27:46 +0000
> "Robin H. Johnson" <robbat2@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

[grozin]

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/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
uid                 [ultimate] <my_name> <my_gentoo_email_address> 
sub   4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]

So, my key id is 0x<16_hex_digits_1>, right?

3. Now I do

gpg --edit-key 0x<16_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/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
uid                 [ultimate] <my_name> <my_gentoo_email_address>
sub   4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
sub   4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26]

4. I do

gpg --output revoke.asc --gen-revoke 0x<16_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-fpr@notations.openpgp.fifthhorseman.net=%g
I don't understand this.

5. I do

gpg --keyserver subkeys.pgp.net --send-key 0x<16_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> 0x<16_hex_digits_1>? Or 0x<16_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="0x<16_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

[Luis Ressel]

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

On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT)
grozin@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/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
> uid                 [ultimate] <my_name> <my_gentoo_email_address> sub   4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
> So, my key id is 0x<16_hex_digits_1>, right?

Yep, but why did you bother to replace the information?

> 3. Now I do
> gpg --edit-key 0x<16_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/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
> uid                 [ultimate] <my_name> <my_gentoo_email_address>
> sub   4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
> sub   4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26]
> 4. I do
> gpg --output revoke.asc --gen-revoke 0x<16_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-fpr@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 0x<16_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> 0x<16_hex_digits_1>? Or 0x<16_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="0x<16_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

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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

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)
> grozin@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 0x<16_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/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
> > uid                 [ultimate] <my_name> <my_gentoo_email_address>
> > sub   4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
> > sub   4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26]
> > 4. I do
> > gpg --output revoke.asc --gen-revoke 0x<16_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-fpr@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 0x<16_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> 0x<16_hex_digits_1>? Or 0x<16_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="0x<16_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...
But THANK YOU for writing up your email, it's great to have somebody
with no experience try the instructions, and help us figure out where
they need to improve.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[-- Attachment #2: gpg-backup --]
[-- Type: text/plain, Size: 916 bytes --]

#!/bin/sh
T="$(date -u +%Y%m%dT%H%M%SZ)"
OUTDIR=~/.gnupg/backup/
COMPRESS_SUFFIX='.gz'
COMPRESS="gzip -9"
USE_ASCII=0
EXPORTOPTS="--export-options export-local-sigs,export-attributes,export-sensitive-revkeys"

dobackup() {
	OPT="$1"
	OFILE="$2"
	TMP="$(mktemp --tmpdir=$OUTDIR tmp.XXXXXXXXXX)"
	gpg ${OPT} | ${COMPRESS} >"$TMP" && mv "$TMP" "$OFILE"
	rm -f "$TMP"
}

ASCII_OPT=''
ASCII_SUFFIX=''
if [[ $USE_ASCII -eq 1 ]]; then
	ASCII_OPT='--armor'
	ASCII_SUFFIX='.asc'
fi

dobackup "${EXPORTOPTS} --export-ownertrust" "${OUTDIR}/${T}.ownertrust.txt${COMPRESS_SUFFIX}"

dobackup "${EXPORTOPTS} ${ASCII_OPT} --export" "${OUTDIR}/${T}.pubkey${ASCII_SUFFIX}${COMPRESS_SUFFIX}"

dobackup "${EXPORTOPTS} ${ASCII_OPT} --export-secret-keys" "${OUTDIR}/${T}.seckey${ASCII_SUFFIX}${COMPRESS_SUFFIX}"

dobackup "${EXPORTOPTS} ${ASCII_OPT} --export-secret-subkeys" "${OUTDIR}/${T}.seckey-sub${ASCII_SUFFIX}${COMPRESS_SUFFIX}"

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Alec Warner]

On Wed, Feb 27, 2013 at 11:04 AM, Robin H. Johnson <robbat2@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)
>> grozin@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 0x<16_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/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
>> > uid                 [ultimate] <my_name> <my_gentoo_email_address>
>> > sub   4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
>> > sub   4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26]
>> > 4. I do
>> > gpg --output revoke.asc --gen-revoke 0x<16_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-fpr@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 0x<16_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> 0x<16_hex_digits_1>? Or 0x<16_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
>> > PORTAGE_GPG_KEY="0x<16_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...
> But THANK YOU for writing up your email, it's great to have somebody
> with no experience try the instructions, and help us figure out where
> they need to improve.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail     : robbat2@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[grozin]

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

[justin]

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

On 14/03/13 04:50, grozin@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


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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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, grozin@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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Zac Medico]

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

[Michał Górny]

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

On Thu, 14 Mar 2013 08:26:04 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Zac Medico]

On 03/14/2013 09:14 AM, Michał Górny wrote:
> On Thu, 14 Mar 2013 08:26:04 -0700
> Zac Medico <zmedico@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

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Michael Mol]

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

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.


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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Michael Mol]

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

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.



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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Michał Górny]

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

On Fri, 15 Mar 2013 03:18:18 +0000
"Robin H. Johnson" <robbat2@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

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Robin H. Johnson]

On Fri, Mar 15, 2013 at 05:44:20AM +0100, Michał Górny wrote:
> On Fri, 15 Mar 2013 03:18:18 +0000
> "Robin H. Johnson" <robbat2@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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[grozin]

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, grozin@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 2>&1
fi

grozin@elrond ~/.gnupg $ cat gpg-agent.conf
pinentry-program /usr/bin/pinentry-qt4
no-grab
default-cache-ttl 100000

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.Bassett@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.Bassett@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

[Panagiotis Christopoulos]

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

On 13:37 Fri 22 Mar     , grozin@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 )

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

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[grozin]

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

[David Abbott]

On Fri, Mar 22, 2013 at 4:47 AM,  <grozin@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/