D346: 760_0001-gpg-Fix-documentation-for-calc_header_length.patch

Patch attached. Is this okay to apply?

Needs to be documented. I see no reason to change this because because it has
no effect.

Also the pinentry.sh script does not look like being called during the opengpg
tests at all because I've added 'exit 1' directly to the beginning of it and
nothing changed even with the gnupg-2.1.10 make check which passed.

This is what I see in strace log from the gpg-agent during the test - so it is
related to addition of the progress messages.

26074 read(4, "PRESET_PASSPHRASE 50B2D4FA4122C2"..., 1002) = 69
26074 getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 2622}, ...}) = 0
26074 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 2652041}) = 0
26074 write(4, "S PROGRESS open_dev_random X 1 0", 32) = 32
26074 write(4, "\n", 1) = 1
26074 open("/dev/urandom", O_RDONLY) = 5
26074 fcntl(5, F_GETFD) = 0
26074 fcntl(5, F_SETFD, FD_CLOEXEC) = 0
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"\224l\240\r\205PGH:;\227\370pv\355\202df\24\201\250\272p\257\334\2\304Z\177W\244Q"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"\222\251\303;\247\377\302Z\t[\10\354\217\236\357?\323\246\210]+\330\341\335*7\315\17\230\3141\211"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"}\37\0267k\343DGi\372\r&\3El\305\223\312|\307\200U6\24RI\6\214\4H\273\377"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"\21%\26k\326\1\232\204K\r\33\216\211\1\253;\324\346\362\203?g\22\315\205\203G\344AZ\272\270"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 2971}, ...}) = 0
26074 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 2978843}) = 0
26074 write(4, "OK", 2) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(2, "gpg-agent[26040]: Assuan process"..., 55) = 55
26074 write(2, "\n", 1) = 1
26074 close(4) = 0

English original (key info anonymized):

gpg2 --edit-key [keyID]
[version info, copyright/license info]

This key may be revoked by RSA key [keyID] [?]
This key may be revoked by RSA key [keyID] [?]
This key may be revoked by RSA key [keyID] [?]
pub [key size]/[keyID] created: [creation date] expires: [date of expiry]
usage: SC

trust: unknown       validity: unknown

[ trust] (1). [uid]

Misleading German translation:

gpg2 --edit-key [keyID]
[version info, copyright/license info]

Dieser Schlüssel könnte durch RSA mit Schlüssel [keyID] [?] widerrufen worden sein
Dieser Schlüssel könnte durch RSA mit Schlüssel [keyID] [?] widerrufen worden sein
Dieser Schlüssel könnte durch RSA mit Schlüssel [keyID] [?] widerrufen worden sein
pub [key size]/[keyID] erzeugt: [creation date] verfällt: [date of expiry]
Aufruf: SC

Vertrauen: unbekannt     Gültigkeit: unbekannt

[ trust] (1). [uid]

Improved German translation:

Dieser Schlüssel kann von RSA-Schlüssel [keyID] [?] widerrufen werden
...

I'm happy to see GnuPG moving to an all-agent model, where the passphrase and
the asymmetric secret key material aren't available to the gpg process.

That sai, if gpgme is going to remove the passphrase_cb prompt, or to deprecate
it in all cases other than symmetric data encryption/decryption, then should the
API change?

gpgme_set_passphrase_cb is used in about 40 packages in debian:

  https://codesearch.debian.net/results/gpgme_set_passphrase_cb/page_0

this includes bindings for python, ruby, php, and c++ -- and it's possible that
those bindings themselves have some other usage elsewhere.

Do we have guidance for users of this function, whether it's with gpgme
directly, or with any of the bindings?

I have the same problem when building gnupg2 on Fedora 23. Let me know if I can
help with debugging it.

Thanks. This seems to be a gpg 1.4 only bug.

Werner Koch via BTS:

Werner Koch <wk@gnupg.org> added the comment:

Sorry, the logs do not help very much. There is a problem with the pjnentry
which for the tests is a simple script and not the configured one. We need to
replicate the failure to debug it.

I have tested this bug in Debian and Windows.

When running "gpg --gen-key --expert" GPG displays:

     DSA keys may be between 512 and 3072 bits long.

and

     ELG-E keys may be between 512 and 4096 bits long.

however entering 512 will result in

     gpg: keysize invalid; using 2048 bits

     gpg --gen-key --expert
     gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
     This is free software: you are free to change and redistribute it.
     There is NO WARRANTY, to the extent permitted by law.

     Please select what kind of key you want:
        (1) RSA and RSA (default)
        (2) DSA and Elgamal
        (3) DSA (sign only)
        (4) RSA (sign only)
        (7) DSA (set your own capabilities)
        (8) RSA (set your own capabilities)
     Your selection? 2

--> DSA keys may be between 512 and 3072 bits long.

What keysize do you want? (2048) 512
Requested keysize is 512 bits

--> ELG-E keys may be between 512 and 4096 bits long.

     What keysize do you want for the subkey? (2048) 512
     Requested keysize is 512 bits
     Please specify how long the key should be valid.
              0 = key does not expire
           <n>  = key expires in n days
           <n>w = key expires in n weeks
           <n>m = key expires in n months
           <n>y = key expires in n years
     Key is valid for? (0) 0
     Key does not expire at all
     Is this correct? (y/N) y

     You need a user ID to identify your key; the software constructs the user ID
     from the Real Name, Comment and Email Address in this form:
         "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

     Real name: user_id
     Email address:
     Comment:
     You selected this USER-ID:
         "user_id"

     Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
     You need a Passphrase to protect your secret key.

     You don't want a passphrase - this is probably a *bad* idea!
     I will do it anyway.  You can change your passphrase at any time,
     using this program with the option "--edit-key".

     We need to generate a lot of random bytes. It is a good idea to perform
     some other action (type on the keyboard, move the mouse, utilize the
     disks) during the prime generation; this gives the random number
     generator a better chance to gain enough entropy.

--> gpg: keysize invalid; using 2048 bits

gpg: WARNING: some OpenPGP programs can't handle a DSA key with this digest

size

...[truncated]...
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

--> gpg: keysize invalid; using 2048 bits

     ...[truncated]...

     gpg: key F0E7A41B marked as ultimately trusted
     public and secret key created and signed.

     gpg: checking the trustdb
     gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
     gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
     pub   2048D/F0E7A41B 2016-02-01
           Key fingerprint = C789 E572 4A8B BC1B 3108  F34E 36F4 D0CC F0E7 A41B
     uid                  user_id
     sub   2048g/977768CF 2016-02-01

Please try 2.1.11 - we fixed something in regard to this.

Sorry, the logs do not help very much. There is a problem with the pjnentry
which for the tests is a simple script and not the configured one. We need to
replicate the failure to debug it.

Jens,
thanks for the report. Now I can classify this as GnuPG "modern" issue. :)
Bernhard

Please explain what you are eactly doing: Give the command typed and all output.
What OS are you using.

In fact Luca' key can currently be found on the keyserver pool with badly
ordered packets (I can provide a copy if need be):

~$ gpg2 --homedir="$gnupghome" --keyserver-options import-minimal --keyserver

hkp://pool.sks-keyservers.net --recv-key "$key"

~$ gpg2 --homedir="$gnupghome" --with-colons --list-sigs "$key" | grep -E

'^(pub|sub|uid|sig:([^:]*:){3}(06EAA066E397832F|39278DA8109E6244)):'

pub:-:4096:1:06EAA066E397832F:1246459499:::-:::scESCA:::::::
uid:-::::1286747091::B41FA634ADD68A6717D380A790190CB3BC80005B::Luca Capello

<luca@pca.it>:::::::::

sig:::1:06EAA066E397832F:1286747091::::Luca Capello <luca@pca.it>:13x:::::8:
uid:-::::1286747538::3590ECEB44695F2B0D4E5B2E85EDBBF99C3A90C6::Luca Capello

<gismo@debian.org>:::::::::

sig:::1:06EAA066E397832F:1286747538::::Luca Capello <luca@pca.it>:13x:::::8:
uid:-::::1453646682::8523545E8C0C86F63F6FC3387DE2D188A55481AF::Luca Capello

<luca.capello@infomaniak.ch>:::::::::

sig:::1:06EAA066E397832F:1453646682::::Luca Capello <luca@pca.it>:13x:::::10:
uid:-::::1454107799::45C4E00E6D5D53EDE22B1CC8D2B44DCE3E3E93B5::Luca Capello

<luca.capello@infomaniak.com>:::::::::

  sig:::1:06EAA066E397832F:1454107799::::Luca Capello <luca@pca.it>:13x:::::10:
  sub:-:4096:1:90C02DEC2BB95F4B:1246460155::::::e::::::
  sig:::1:06EAA066E397832F:1246460155::::Luca Capello <luca@pca.it>:18x:::::8:
  sub:-:4096:1:D91D57A03BE9F36D:1246460943::::::esa::::::
  sig:::1:39278DA8109E6244:1360031056::::[User ID not found]:10x:::::10:
  sig:::1:06EAA066E397832F:1246459499::::Luca Capello <luca@pca.it>:13x:::::8:
  sig:::1:06EAA066E397832F:1246460297::::Luca Capello <luca@pca.it>:13x:::::8:
  sig:::1:06EAA066E397832F:1286747091::::Luca Capello <luca@pca.it>:13x:::::8:
  sig:::1:06EAA066E397832F:1246460943::::Luca Capello <luca@pca.it>:18x:::::8:

Is there any reason why --import/--recv-key didn't move the packets to their
proper place? After all the keyring is then open in write mode.

Moreover while --edit attempts to reorder the packets, it places the signature
packets under the wrong UID:

~$ gpg2 --homedir="$gnupghome" --edit "$key" save
[…]
gpg: moving a key signature to the correct place
~$ gpg2 --homedir="$gnupghome" --with-colons --list-sigs "$key" | grep -E

'^(pub|sub|uid|sig:([^:]*:){3}(06EAA066E397832F|39278DA8109E6244)):'

pub:-:4096:1:06EAA066E397832F:1246459499:::-:::scESCA:::::::
uid:-::::1286747091::B41FA634ADD68A6717D380A790190CB3BC80005B::Luca Capello

<luca@pca.it>:::::::::

sig:::1:06EAA066E397832F:1286747091::::Luca Capello <luca@pca.it>:13x:::::8:
uid:-::::1286747538::3590ECEB44695F2B0D4E5B2E85EDBBF99C3A90C6::Luca Capello

<gismo@debian.org>:::::::::

sig:::1:06EAA066E397832F:1286747538::::Luca Capello <luca@pca.it>:13x:::::8:
uid:-::::1453646682::8523545E8C0C86F63F6FC3387DE2D188A55481AF::Luca Capello

<luca.capello@infomaniak.ch>:::::::::

sig:::1:06EAA066E397832F:1453646682::::Luca Capello <luca@pca.it>:13x:::::10:
uid:-::::1454107799::45C4E00E6D5D53EDE22B1CC8D2B44DCE3E3E93B5::Luca Capello

<luca.capello@infomaniak.com>:::::::::

  sig:::1:06EAA066E397832F:1454107799::::Luca Capello <luca@pca.it>:13x:::::10:
  sig:::1:06EAA066E397832F:1286747091::::Luca Capello <luca@pca.it>:13x:::::8:
  sig:::1:06EAA066E397832F:1246460297::::Luca Capello <luca@pca.it>:13x:::::8:
  sig:::1:06EAA066E397832F:1246459499::::Luca Capello <luca@pca.it>:13x:::::8:
  sig:::1:39278DA8109E6244:1360031056::::[User ID not found]:10x:::::10:
  sub:-:4096:1:90C02DEC2BB95F4B:1246460155::::::e::::::
  sig:::1:06EAA066E397832F:1246460155::::Luca Capello <luca@pca.it>:18x:::::8:
  sub:-:4096:1:D91D57A03BE9F36D:1246460943::::::esa::::::
  sig:::1:06EAA066E397832F:1246460943::::Luca Capello <luca@pca.it>:18x:::::8:

I (0x39278DA8109E6244) did *not* sign Luca's 4th UID. I'm unsure (based on
--list-packets' output) which of the 2 first UIDs my signature applies to, but
certainly not to the last two, which were created 3 years after my sig was
issued.

In fact this is reproducible with Luca's key (but strangely not with mine):

~$ gpg2 --version
gpg (GnuPG) 2.1.11
~$ gnupghome=$(mktemp -d)
~$ key=0x06EAA066E397832F
~$ gpg2 --homedir="$gnupghome" --keyserver hkp://pool.sks-keyservers.net

--recv-key "$key"

~$ gpg2 --homedir="$gnupghome" --edit-key "$key" minimize 4 deluid save
~$ gpg2 --homedir="$gnupghome" --keyserver hkp://pool.sks-keyservers.net

--recv-key "$key"

  ~$ gpg2 --homedir="$gnupghome" --with-colons --list-sigs "$key"

The last command shows a lot of signatures under the last subkey. This not only
messes up the parsing, but also confuses GnuPG: for instance it refuses to let
me sign the 4th UID because it thinks I already did.

Hi Bernhard,

all concatenated tests 2.1.10 by contrast
hope it helps

all concatenated tests

This is likey due to the card already decoding the pkcs#1 - we need to look
closer at this use case.

For reference, I have a OpenPGP v2.0 card from "ZeitControl".

I think the card will always remove the encoding internally and only return the
plaintext, as far as I can tell from
http://g10code.com/docs/openpgp-card-2.0.pdf, Section 7.2.9

check out tests/openpgp/version.test.log or the oter *test.log files.

Look here:

gpgsm: DBG: pkcs1 encoded session key: 11 E8 C4 40 93 A8 24 35 16 57 93 8D 03 00
63 5F
gpgsm: decrypting session key failed: Invalid session key

This is clearly not a PKCS#1 encoded session key but a plain session key. This
is likey due to the card already decoding the pkcs#1 - we need to look closer at
this use case.

Hi Jens,
which version of gpg2 on which platform did you try this?

Which version of gnupg2 do you refer to? (On which platform?)
AFAIK 2.0.29 gpg2 does not have a --faked-system-time option.

Thanks for looking at this!

I am on openSUSE (Tumbleweed), my gnupg version is
lorenz@host:~/gpgsm_problem> gpgsm --version
gpgsm (GnuPG) 2.1.10
libgcrypt 1.6.4
libksba 1.3.3
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Cipher: 3DES, AES128, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, SEED,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Pubkey: RSA, ECC
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL

If I run

  gpgsm --debug 4 -d gpgsm_encrypted

the same session key is printed that my script got

Here is a full transcript:

lorenz@host:~/gpgsm_problem> gpgsm --debug 4 -d gpgsm_encrypted
gpgsm: reading options from '/home/lorenz/.gnupg/gpgsm.conf'
gpgsm: enabled debug flags: crypto
gpgsm: failed to open '/home/lorenz/.gnupg/policies.txt': No such file or directory
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28
31 3A 73 32 35 36 3A 75 46 91 66 A9 B6 A0 46 03 85 68 F1 E8 A5 37 14 30 BA E5 B6
A2 D6 5C E8 26 31 C7 9A AF 27 96 54 CD 6D 73 8C 70 73 CA C9 E9 73 9C E2 B3 5E 50
9B 7D 6A 5E C7 9E C4 34 FE 1B E1 9C DC 14 56 3F F4 29 A2 07 47 9D A5 5D 0E BE C3
F3 6E E6 49 3C 96 BB 43 3A 5B 1C 56 10 E3 3B 0C 3F 67 2F 31 B9 BF B7 38 4F CA C7
55 20 AC 50 76 6A CB FC C9 15 29 D5 10 89 31 88 A9 87 ED DC 2B A3 7C 22 E5 04 4F
16 A8 32 DF 62 56 B1 88 C8 80 0B 4B 93 E7 8A D4 35 D3 14 62 40 FB 87 82 EF E3 4F
DE ED 27 BF 0B 01 B1 49 C5 20 03 1A 04 87 31 55 14 7F B3 91 31 8A A8 E5 0C CF CE
25 77 6C A1 5C 5D EB 74 D5 28 4D DB 90 6A 87 B3 91 48 A0 72 10 2C C7 DD DA 2F E0
2E AA D1 BD D0 16 50 DB 30 12 08 C4 3A 62 DB 4F 77 E1 5E 18 ED 22 C1 70 32 2F C3
6A DE 66 B2 47 52 48 B2 86 B1 32 6C 6E 27 04 12 A8 E1 48 8A 29 29 28 34 3A 68 61
73 68 36 3A 73 68 61 32 35 36 29 29
gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 31
30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 82 A4 B2 5B 4E 14 77 27 0B 73
12 97 8F 56 FC 61 42 7E 37 3F 8B 74 3F 4E 40 2D 38 C1 08 47 32 6C
DBG: rsa_verify
data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d06096086480165030402010500042082 \
DBG: a4b25b4e1477270b7312978f56fc61427e373f8b743f4e402d38c10847326c
DBG: rsa_verify
sig:+75469166a9b6a046038568f1e8a5371430bae5b6a2d65ce82631c79aaf279654 \
DBG:
cd6d738c7073cac9e9739ce2b35e509b7d6a5ec79ec434fe1be19cdc14563ff4 \
DBG:
29a207479da55d0ebec3f36ee6493c96bb433a5b1c5610e33b0c3f672f31b9bf \
DBG:
b7384fcac75520ac50766acbfcc91529d510893188a987eddc2ba37c22e5044f \
DBG:
16a832df6256b188c8800b4b93e78ad435d3146240fb8782efe34fdeed27bf0b \
DBG:
01b149c520031a04873155147fb391318aa8e50ccfce25776ca15c5deb74d528 \
DBG:
4ddb906a87b39148a072102cc7ddda2fe02eaad1bdd01650db301208c43a62db \
DBG:
4f77e15e18ed22c170322fc36ade66b2475248b286b1326c6e270412a8e1488a
DBG: rsa_verify
n:+d851729ea0d4cb8241b06da9e2e2b96e6b98f39732127c79da8ffe6a4be9a88d \
DBG:
0a80fde61ad1b1ae732955e61c90bb2273edde2045c91d84c0d5f03648c44454 \
DBG:
22c1655c58fa1c61e36998e58481dba384b5d868cb8531f9619dfb3bb307570d \
DBG:
0bfc9861cd423111233565f453ff12ea873da27496234fdf16f4e16fccf813d3 \
DBG:
2add89e33390b533e57fdfa58f0cbb26018319dd741251c3a66d9617429a5e05 \
DBG:
f10df9a526fc276a80362c2e255bb75824e02ffc9da37780f2f0e278c319ecef \
DBG:
8bd700270b305b1c08c9e47eb153507b9a5c26bbb577a53a0a3e07169a53b41d \
DBG:
c4e96baf0c70d4c61a263ca4ed3f467d5f5e4a8361ff33d253dd5945b16ccd51
DBG: rsa_verify e:+010001
DBG: rsa_verify
cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d06096086480165030402010500042082 \
DBG: a4b25b4e1477270b7312978f56fc61427e373f8b743f4e402d38c10847326c
DBG: rsa_verify => Good
gpgsm: certificate is good
gpgsm: failed to open '/home/lorenz/.gnupg/policies.txt': No such file or directory
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28
31 3A 73 32 35 36 3A 3F DC 77 C2 D3 F0 64 6C AE 20 91 39 59 AF F4 E8 EC B3 F2 B4
BA 19 9A 85 9D 7B 8D 07 59 B8 F8 38 FF 54 7D 5D 80 5D 5B 7C B2 9B 86 48 61 6B DB
ED 8B DD 8E 78 1B 5D 62 0F E6 CF CA AF 78 52 64 7E B7 74 5C F0 57 FF 15 EA 7E DE
E7 A5 CA 73 DE F6 F5 B4 1D B9 39 C0 B3 EF 98 4F 15 14 CB 4E 69 16 76 B8 EC DB FD
04 26 E2 4B 91 13 5D 42 99 3C C2 09 03 4D 57 C0 0E F2 5E 41 4F F9 B4 5D 98 94 6C
16 7F 30 78 A6 E3 9C E1 35 76 6E B8 B5 7E AE A5 F3 F5 37 C8 56 90 67 EC 23 0C 8E
D8 DE 3B 49 31 EB BF 4F D5 3E 51 E1 2B 16 1D 2D 64 34 EE A6 C4 D6 9F C8 BD 05 B2
98 84 90 7B 02 C1 8E 63 BB DA 05 81 E2 87 06 03 67 D3 AC 3E F7 C2 7D BD 5F 86 6C
47 51 E7 D3 9C 62 E8 F2 D0 D3 A1 D0 3B 11 91 AD 2F 5E 10 3D 14 42 81 D8 CD FD 45
D1 AD E8 FB 36 3A 3A 7C 8D 69 C0 A6 77 85 6B 60 67 52 B4 1C 29 29 28 34 3A 68 61
73 68 36 3A 73 68 61 32 35 36 29 29
gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 31
30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 AC 84 B9 EC BF F8 15 90 76 00
F8 4A 76 2E 6E 51 C9 40 2B 43 D9 FB 28 C4 C1 E1 94 EC D5 14 4B D0
DBG: rsa_verify
data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420ac \
DBG: 84b9ecbff815907600f84a762e6e51c9402b43d9fb28c4c1e194ecd5144bd0
DBG: rsa_verify
sig:+3fdc77c2d3f0646cae20913959aff4e8ecb3f2b4ba199a859d7b8d0759b8f838 \
DBG:
ff547d5d805d5b7cb29b8648616bdbed8bdd8e781b5d620fe6cfcaaf7852647e \
DBG:
b7745cf057ff15ea7edee7a5ca73def6f5b41db939c0b3ef984f1514cb4e6916 \
DBG:
76b8ecdbfd0426e24b91135d42993cc209034d57c00ef25e414ff9b45d98946c \
DBG:
167f3078a6e39ce135766eb8b57eaea5f3f537c8569067ec230c8ed8de3b4931 \
DBG:
ebbf4fd53e51e12b161d2d6434eea6c4d69fc8bd05b29884907b02c18e63bbda \
DBG:
0581e287060367d3ac3ef7c27dbd5f866c4751e7d39c62e8f2d0d3a1d03b1191 \
DBG:
ad2f5e103d144281d8cdfd45d1ade8fb363a3a7c8d69c0a677856b606752b41c
DBG: rsa_verify
n:+e99bc36785f90daef58d54c39650353d62e96e4ced94d7005b952274d420eb34 \
DBG:
8fd6ecc031040b9981e2a614d252a02823848b7489045e5be0e278c178cb16cb \
DBG:
2835397b2d9045d0eda0007a7cbf4a0e1b00c386e95c2b31117b0cf38224438c \
DBG:
1c388b6a68009aeedc4f78abd2c6139b76adeede26e8ef01af740fc109a2f66b \
DBG:
cebdd3cd14304ff5e5e3a4c8629b821a0327300d0265604dedd109232a963558 \
DBG:
27d376c671b6901dc4edff35867d6f33b3db0fc511c28a83a1945d416bd8d210 \
DBG:
f54cfdca51acd9bdef9283bbdaeb8b16565643cfe1d5133da61f2730cd4954db \
DBG:
c913349a7175c56ceaa70b98f9219d27af3ea33939486a8cadc999fbc312f2bd
DBG: rsa_verify e:+010001
DBG: rsa_verify
cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420ac \
DBG: 84b9ecbff815907600f84a762e6e51c9402b43d9fb28c4c1e194ecd5144bd0
DBG: rsa_verify => Good
gpgsm: intermediate certificate is good
gpgsm: failed to open '/home/lorenz/.gnupg/policies.txt': No such file or directory
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28
31 3A 73 32 35 36 3A 63 20 28 FD 9C 21 86 72 BE 39 46 59 39 32 25 BC A9 01 9B 0D
CC CA 7D 41 9C 86 6D 0A 6E 2C B3 13 59 75 B1 33 92 1B 61 27 16 FF C3 B2 D5 35 82
FB 84 2A 01 49 BD 66 BB 66 2F B2 C2 06 5D 6E 3F 6E E3 01 5A 5B CA 43 63 5C 95 B6
E1 31 A7 1F D5 07 5F 4D E6 65 82 4E 32 F9 C3 7C 7A 4B CD 4D 5C 74 EE 21 F2 75 02
EC 52 3E D2 C9 6A D3 90 23 6E 49 67 35 BE 7F 4D 56 A4 EC CC 2F CF B7 A1 97 A8 72
3E C9 BC 40 D6 5A A4 08 3D D6 BC 82 C3 B7 B7 32 8E B1 2C 8E 6A 6D B7 35 02 19 CF
F5 39 44 58 63 A7 24 00 10 B0 BB FC 4E AF 6E 2F 38 BB A5 57 49 3F D8 6E 50 6F 2C
97 96 DC 1D 46 9A 65 89 CF AE CC F2 E5 D9 9F 53 B3 3E A1 2F 92 A9 D8 0B C6 84 1F
04 C6 EB 1E E8 9F 7D B5 7B A5 02 F1 24 C5 24 63 11 34 CC 5A 93 20 2A 79 88 3A 25
42 90 A9 65 3B 7C 86 D3 12 15 23 29 FC 2C DA CC 39 5B 54 17 29 29 28 34 3A 68 61
73 68 36 3A 73 68 61 32 35 36 29 29
gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 31
30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 DF 7B C9 01 35 70 5A 34 2B 30
ED 96 C6 35 7F 80 51 5A 56 9C B6 89 F2 9D 69 DE E4 02 3F 5E 7C 9A
DBG: rsa_verify
data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420df \
DBG: 7bc90135705a342b30ed96c6357f80515a569cb689f29d69dee4023f5e7c9a
DBG: rsa_verify
sig:+632028fd9c218672be394659393225bca9019b0dccca7d419c866d0a6e2cb313 \
DBG:
5975b133921b612716ffc3b2d53582fb842a0149bd66bb662fb2c2065d6e3f6e \
DBG:
e3015a5bca43635c95b6e131a71fd5075f4de665824e32f9c37c7a4bcd4d5c74 \
DBG:
ee21f27502ec523ed2c96ad390236e496735be7f4d56a4eccc2fcfb7a197a872 \
DBG:
3ec9bc40d65aa4083dd6bc82c3b7b7328eb12c8e6a6db7350219cff539445863 \
DBG:
a7240010b0bbfc4eaf6e2f38bba557493fd86e506f2c9796dc1d469a6589cfae \
DBG:
ccf2e5d99f53b33ea12f92a9d80bc6841f04c6eb1ee89f7db57ba502f124c524 \
DBG:
631134cc5a93202a79883a254290a9653b7c86d312152329fc2cdacc395b5417
DBG: rsa_verify
n:+ab0ba335e08b2914b11485af3c10e4396f355d4aaeddea618d9549f46f64a31a \
DBG:
6066a4a9402284d9d4a5e578930e6801adb94d5c3aced3b8a84240dfcfa3ba82 \
DBG:
596a921bac1c9ada082b2527f9692347f1e0eb2c7a9bf51302d07e347cc29e3c \
DBG:
0059abf5da0cf5323c2bac50dad6c3de8394caa80c99320e0848565b6afbdae1 \
DBG:
585801495f72413c1506018e5dadaab893b4cd9eeba7e86a2d5234db3aef5c75 \
DBG:
51dadbf331f9ee719832c45415440cf99b55edaddf1808a0a3868a49ee53058f \
DBG:
194cd5de58799bd26a1c42abc5d5a7cf680f96e4e161987661c8917cd63e00e2 \
DBG:
915087e19d0ae6ad97d21dc63a7dcbbcda0334d58e5b01f56a07b716b66e4a7f
DBG: rsa_verify e:+010001
DBG: rsa_verify
cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
DBG:
ffffffffffffffffffffff003031300d060960864801650304020105000420df \
DBG: 7bc90135705a342b30ed96c6357f80515a569cb689f29d69dee4023f5e7c9a
DBG: rsa_verify => Good
gpgsm: root certificate is good
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: validation model used: shell
gpgsm: DBG: recp 0 - issuer: 'CN=mail@example.com'
gpgsm: DBG: recp 0 - serial: 52DF665BB71FAF4F
gpgsm: DBG: pkcs1 encoded session key: 11 E8 C4 40 93 A8 24 35 16 57 93 8D 03 00
63 5F
gpgsm: decrypting session key failed: Invalid session key
gpgsm: message decryption failed: No secret key <GpgSM>
secmem usage: 0/16384 bytes in 0 blocks

Which OS and which gnupg version are you using?

Use

gpgsm --debug 4 -d gpgsm_encrypted

to see the session key before gpgsm detects thaty it is invalid.

Meanwhile the toggle command is a dummy and the extra infos for secret keys are
always displayed.

I commited an adjusted patch for GnuPG 2.1 (3e50236).

Thanks. I did some modifications and also fixed an unrelated bug in the
detection of the poolname. Will go into 2.1.11.

Please describe your problem and do not just post a picture, schreenshort or
whatever. See https://bugs.gnupg.org on how to send a bug report.

From the title of your report it seems to be more a question than a bug - please
ask on one of the mailing lists for help.

The text now reads:

This is a revocation certificate for the OpenPGP key:

pub rsa2048/71201A64 2016-01-21

Key fingerprint = F6B8 598F 5E71 5104 D13C  1415 58D4 85FF 7120 1A64

uid baz@example.org

A revocation certificate is a kind of "kill switch" to publicly
declare that a key shall not anymore be used. It is not possible
to retract such a revocation certificate once it has been published.

Use it to revoke this key in case of a compromise or loss of
the secret key. However, if the secret key is still accessible,
it is better to generate a new revocation certificate and give
a reason for the revocation. For details see the description of
of the gpg command "--gen-revoke" in the GnuPG manual.

To avoid an accidental use of this file, a colon has been inserted
before the 5 dashes below. Remove this colon with a text editor

before importing and publishing this revocation certificate.

This is caused by gpg inability of merging the secret keys. We can't fix that
in 1.4 or 2.0. 2.1 does not have this problem anymore.

Fixed with commit 09117e7 to be released with 2.1.11