Bug#797712: failing with gpg2, error reading key: Legacy key

[Eduard Bloch]

Hallo,
* Guilhem Moulin [Thu, Sep 03 2015, 11:46:42AM]:
> Control: tag -1 moreinfo unreproducible
> 
> On Wed, 02 Sep 2015 at 22:20:03 +0200, Eduard Bloch wrote:
> > $ gpg2 --homedir ~/.caff/gnupghome.alt --list-key 
> > 7C3AB9CFD230BD30DD009C591E7091B1F14A64A2
> > gpg: checking the trustdb
> > gpg: keydb_get_keyblock failed: Legacy key
> > gpg: keydb_get_keyblock failed: Legacy key
> > gpg: keydb_get_keyblock failed: Legacy key
> > ... LOTS OF THEM ...
> > gpg: keydb_get_keyblock failed: Legacy key
> > gpg: no ultimately trusted keys found
> > pub   rsa4096/F14A64A2 2009-05-22 [expires: 2017-07-21]
> > uid [ unknown] Aaron M. Ucko 
> > uid [ unknown] Aaron M. Ucko 
> > uid [ unknown] [jpeg image of size 6064]
> > sub   rsa4096/0ABAADF9 2009-05-22 [expires: 2017-07-21]
> 
> What's the return value of that command btw?  Does running the command a
> second time afterwards (with the GNUPGHOME left by the first execution)
> produce the same output and return value?  Same question with
> ‘--trust-model=always’.
> 
> Also, do you have any v3 keys in your keyring?  What's the output of
> 
>   gpg --homedir ~/.caff/gnupghome.alt --with-fingerprint --with-fingerprint 
> --with-colons --list-keys |
>   grep -icE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$'
> 
> (you need to set ‘--with-fingerprint’ twice to list subkey fingerprints
> as well.)

84

;-) Have I mentioned that I installed signing-party a decade ago and used it
rarelly, like once in 2-3 years?

$ stat secring.gpg 
  File: ‘secring.gpg’
...
Modify: 2006-05-06 13:19:30.0 +0200

Regards,
Eduard.


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

Two more things: do you have v3 private material as well?  You can count
them with

  gpg --with-fingerprint --with-fingerprint --with-colons --list-secret-keys |
  grep -icE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$'

Are the key(s) specified in your ~/.caffrc (‘keyid’, ‘also-encrypt-to’,
‘local-user’) all v4 keys?

-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

On Thu, 03 Sep 2015 at 19:14:59 +0200, Eduard Bloch wrote:
> * Guilhem Moulin [Thu, Sep 03 2015, 11:46:42AM]:
>> Also, do you have any v3 keys in your keyring?  What's the output of
>> 
>> gpg --homedir ~/.caff/gnupghome.alt --with-fingerprint --with-fingerprint 
>> --with-colons --list-keys |
>> grep -icE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$'
>> 
>> (you need to set ‘--with-fingerprint’ twice to list subkey fingerprints
>> as well.)
> 
> 84
> 
> ;-) Have I mentioned that I installed signing-party a decade ago and used it
> rarelly, like once in 2-3 years?

No you did not :-)  v3 keys completely broken and are no longer
supported by GnuPG 2.1.  Caff support for v3 keys was somewhat hackish
at first (2004-2005), then was completely removed in 2005 (r110).

Currently it warns you of the existence of v3 master keys (and ignore
them), but there is no special handling of v3 subkeys.  It looks like
GnuPG 2.1 chokes on v3 (sub)keys; possibly because a trust value has
been assigned to those.

How many of these v3 keys are v3 subkeys of a v4 master key?  Does it
help to delete them?

gpg --homedir ~/.caff/gnupghome.alt --trust-model=always --with-fingerprint 
--with-colons --list-keys |
grep -iE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$' >/tmp/v3-keys

wc -l /tmp/v3-keys

xargs -a /tmp/v3-keys gpg --homedir ~/.caff/gnupghome.alt 
--trust-model=always --batch --delete-keys

caff --debug $KEYID

The above only deal with v3 master keys.  As for v3 subkeys,

gpg --homedir ~/.caff/gnupghome.alt --trust-model=always --with-fingerprint 
--with-fingerprint --with-colons --list-keys |
grep -iE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$' >/tmp/v3-subkeys

wc -l /tmp/v3-subkeys

xargs -a /tmp/v3-subkeys gpg --homedir ~/.caff/gnupghome.alt 
--trust-model=always --batch --delete-keys

caff --debug $KEYID


Thanks for your help in cornering this bug ;-)
Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Eduard Bloch]

Hallo,
* Guilhem Moulin [Wed, Sep 02 2015, 11:49:43PM]:
> Hi,
> 
> On Wed, 02 Sep 2015 at 22:20:03 +0200, Eduard Bloch wrote:
> > * Guilhem Moulin [Tue, Sep 01 2015, 10:43:19PM]:
> >> On Tue, 01 Sep 2015 at 22:11:23 +0200, Eduard Bloch wrote:
> > But I saw no trustdb check when caff is working...
> 
> caff doesn't create a trust database because it doesn't rely on the WoT

caff doesn't but, for example, an obvious step after a KSP is to run gpg
--homedir ~/.caff/gnupghome --import something.gpg (the keyring
distributed for that signing party). This simple operation gets you a
trustdb installed into ~/.caff/gnupghome . And yes, I learned about
--key-file option now after reading the manpage.

However, I am no longer sure that my problem is really related to
trustdb. I just restored the suspicious gnupghome directory then removed
trustdb.gpg there and tried again. Result: the original error "Legacy
key". So, the apparent fix via single --check-db run is probably a red
herring and the original issue (failing automated migration) still
persists.

> > This makes me wonder, I see --no-auto-check-trustdb in your gpg options... 
> > maybe this is the
> > key? It needs to update trustdb prior to migration but it's forbidden.
> 
> Then this should be forwarded to upstream GnuPG. --trust-model=always
> should skip any operation on the trust database, including trust value
> updates.

Ok... it's not explained like this in the manpage but I'd assume it.

> > It shouldn't do anything if no update is needed. I checked that:
> > restored broken dir, reproduced mentioned problem, called the command,
> > watched the update finished, called caff again, and it worked just fine.
> 
> Yes it does something: if a there was no ‘~/.caff/gnupghome/trustdb.gpg’
> file then it is created.  IMHO it's a quite ugly hack to involve a trust
> database operation since caff has never relied on a trust model.  I'll
> rather forward the issue to GnuPG.

Agreed. This whole thing looks more and more like a gpg2 issue.

> Your test shows that gpg2 is able to perform the keyring migration (with
> --trust-model=always) on a fresh ‘~/.caff/gnupghome’, ie, when no trust
> database exists.  So this should only be an issue if you have been
> fiddling around with ‘gpg --homedir ~/.caff/gnupghome’ manually, right?

I only said that --check-trustdb has fixed it and I suspected some
things from that moment. And "manually" is such an ugly word...

Regards,
Eduard.


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

Control: tag -1 moreinfo unreproducible

On Wed, 02 Sep 2015 at 22:20:03 +0200, Eduard Bloch wrote:
> $ gpg2 --homedir ~/.caff/gnupghome.alt --list-key 
> 7C3AB9CFD230BD30DD009C591E7091B1F14A64A2
> gpg: checking the trustdb
> gpg: keydb_get_keyblock failed: Legacy key
> gpg: keydb_get_keyblock failed: Legacy key
> gpg: keydb_get_keyblock failed: Legacy key
> ... LOTS OF THEM ...
> gpg: keydb_get_keyblock failed: Legacy key
> gpg: no ultimately trusted keys found
> pub   rsa4096/F14A64A2 2009-05-22 [expires: 2017-07-21]
> uid [ unknown] Aaron M. Ucko 
> uid [ unknown] Aaron M. Ucko 
> uid [ unknown] [jpeg image of size 6064]
> sub   rsa4096/0ABAADF9 2009-05-22 [expires: 2017-07-21]

What's the return value of that command btw?  Does running the command a
second time afterwards (with the GNUPGHOME left by the first execution)
produce the same output and return value?  Same question with
‘--trust-model=always’.

Also, do you have any v3 keys in your keyring?  What's the output of

  gpg --homedir ~/.caff/gnupghome.alt --with-fingerprint --with-fingerprint 
--with-colons --list-keys |
  grep -icE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$'

(you need to set ‘--with-fingerprint’ twice to list subkey fingerprints
as well.)

I'm afraid it's hard for me to corner the root of the problem.  I tried
to migrate from 1.4 to 2.0 on a GNUPGHOME with and without a trust
database, with and without --trust-model=always, and couldn't reproduce
the issue.  So I guess it's tied to your particular keyring and/or trust
database somehow.

-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

On Tue, 01 Sep 2015 at 22:43:19 +0200, Guilhem Moulin wrote:
> Could you also try to create a fresh caff keyring with gnupg 1.4 and
> later try to run caff with 2.1?  Something like that:
> 
>   mv ~/.caff/gnupghome ~/.caff/gnupghome1
>   # set ‘$CONFIG{'gpg'} = 'gpg';’ in your caffrc
>   caff --debug --no-sign $KEYID
>   # set ‘$CONFIG{'gpg'} = 'gpg2';’ in your caffrc
>   caff --debug $KEYID

So I did just that (with the same $KEYID), gpg was able to migrate
caff's gnupghome to 2.1 just fine.  So I think in your case there is
something in caff's gnupghome that prevents the migration somehow.  Did
GnuPG 2.1 create the file ‘~/.caff/gnupghome/.gpg-v21-migrated’?  Does
either of ‘gpg2 --homedir ~/.caff/gnupghome --list-keys’ or ‘gpg2
--homedir ~/.caff/gnupghome --list-secret-keys’ return a non-zero exit
value?

-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Eduard Bloch]

Hallo,
* Guilhem Moulin [Tue, Sep 01 2015, 10:43:19PM]:
> Hi,
> 
> On Tue, 01 Sep 2015 at 22:11:23 +0200, Eduard Bloch wrote:
> > And for some reason, gpg-agent is no longer working, I guess it's
> > caused by gpg2 installation?
> 
> It has nothing to do with signing-party anyway.

Uhm... see below.

> > The solution is removing .caff/gnupghome and let it replace it. This is
> > either a bug or your docs might point out that it needs to be deleted
> > after changing gpg version.

> Could you also try to create a fresh caff keyring with gnupg 1.4 and
> later try to run caff with 2.1?  Something like that:
> 
> mv ~/.caff/gnupghome ~/.caff/gnupghome1
> # set ‘$CONFIG{'gpg'} = 'gpg';’ in your caffrc
> caff --debug --no-sign $KEYID
> # set ‘$CONFIG{'gpg'} = 'gpg2';’ in your caffrc
> caff --debug $KEYID
> 
> If that works, it might be due to [0] indeed.  Otherwise, it's probably
> a bug in caff ;-)

Yes, the migration of a fresh version worked just as you have expected.

> No action should be required on your side.  Do you still have a copy of
> the ‘~/.caff/gnupghome’?  If yes can you run
> 
>   gpg2 --homedir ~/.caff/gnupghome --list-key $KEYID

I have a backup, indeed...

$ gpg2 --homedir ~/.caff/gnupghome.alt --list-key 
7C3AB9CFD230BD30DD009C591E7091B1F14A64A2
gpg: checking the trustdb
gpg: keydb_get_keyblock failed: Legacy key
gpg: keydb_get_keyblock failed: Legacy key
gpg: keydb_get_keyblock failed: Legacy key
... LOTS OF THEM ...
gpg: keydb_get_keyblock failed: Legacy key
gpg: no ultimately trusted keys found
pub   rsa4096/F14A64A2 2009-05-22 [expires: 2017-07-21]
uid [ unknown] Aaron M. Ucko 
uid [ unknown] Aaron M. Ucko 
uid [ unknown] [jpeg image of size 6064]
sub   rsa4096/0ABAADF9 2009-05-22 [expires: 2017-07-21]

But I saw no trustdb check when caff is working...

This makes me wonder, I see --no-auto-check-trustdb in your gpg options... 
maybe this is the
key? It needs to update trustdb prior to migration but it's forbidden.

So I hacked caff and removed the option but this did not change anything.
Maybe it's not allowed together with --batch? I don't know.

Anyhow, after little RTFM, I think that a possible workaround for this
problem in caff should be calling this always when caff starts:
gpg2 --batch --check-trustdb --homedir ...
It shouldn't do anything if no update is needed. I checked that:
restored broken dir, reproduced mentioned problem, called the command,
watched the update finished, called caff again, and it worked just fine.

> I wonder if it's related to [0] somehow.

Yeah, probably.

Regards,
Eduard.


-- 
 Bücken ist schonmal ganz schlecht.
 Wehe einer wirft mir ein Stück Seife zu!

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

Hi,

On Wed, 02 Sep 2015 at 22:20:03 +0200, Eduard Bloch wrote:
> * Guilhem Moulin [Tue, Sep 01 2015, 10:43:19PM]:
>> On Tue, 01 Sep 2015 at 22:11:23 +0200, Eduard Bloch wrote:
> But I saw no trustdb check when caff is working...

caff doesn't create a trust database because it doesn't rely on the WoT
or any other trust model.  All calls to gpg have the --trust-model=always
option.  The --no-auto-check-trustdb flag is merely added to prevent gpg
from emitting a warning.

> This makes me wonder, I see --no-auto-check-trustdb in your gpg options... 
> maybe this is the
> key? It needs to update trustdb prior to migration but it's forbidden.

Then this should be forwarded to upstream GnuPG. --trust-model=always
should skip any operation on the trust database, including trust value
updates.

Actually if gpg has never been called with another trust model on that
$GNUPGHOME (which should be the case if you never call gpg manually on
‘~/.caff/gnupghome’) the trustdb shouldn't even been created.

> So I hacked caff and removed the option but this did not change anything.
> Maybe it's not allowed together with --batch? I don't know.

No it's not.
 
> Anyhow, after little RTFM, I think that a possible workaround for this
> problem in caff should be calling this always when caff starts:
> gpg2 --batch --check-trustdb --homedir ...
> It shouldn't do anything if no update is needed. I checked that:
> restored broken dir, reproduced mentioned problem, called the command,
> watched the update finished, called caff again, and it worked just fine.

Yes it does something: if a there was no ‘~/.caff/gnupghome/trustdb.gpg’
file then it is created.  IMHO it's a quite ugly hack to involve a trust
database operation since caff has never relied on a trust model.  I'll
rather forward the issue to GnuPG.

Your test shows that gpg2 is able to perform the keyring migration (with
--trust-model=always) on a fresh ‘~/.caff/gnupghome’, ie, when no trust
database exists.  So this should only be an issue if you have been
fiddling around with ‘gpg --homedir ~/.caff/gnupghome’ manually, right?

Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

Hi,

On Tue, 01 Sep 2015 at 22:11:23 +0200, Eduard Bloch wrote:
> And for some reason, gpg-agent is no longer working, I guess it's
> caused by gpg2 installation?

It has nothing to do with signing-party anyway.

> The solution is removing .caff/gnupghome and let it replace it. This is
> either a bug or your docs might point out that it needs to be deleted
> after changing gpg version.

No action should be required on your side.  Do you still have a copy of
the ‘~/.caff/gnupghome’?  If yes can you run

  gpg2 --homedir ~/.caff/gnupghome --list-key $KEYID

I wonder if it's related to [0] somehow.

Could you also try to create a fresh caff keyring with gnupg 1.4 and
later try to run caff with 2.1?  Something like that:

mv ~/.caff/gnupghome ~/.caff/gnupghome1
# set ‘$CONFIG{'gpg'} = 'gpg';’ in your caffrc
caff --debug --no-sign $KEYID
# set ‘$CONFIG{'gpg'} = 'gpg2';’ in your caffrc
caff --debug $KEYID

If that works, it might be due to [0] indeed.  Otherwise, it's probably
a bug in caff ;-)

-- 
Guilhem.

[0] https://bugs.gnupg.org/gnupg/issue1847


signature.asc
Description: Digital signature

Bug#797712: failing with gpg2, error reading key: Legacy key

[Eduard Bloch]

Package: signing-party
Version: 2.1-1
Severity: normal

Hello,

store before: since mutt now depends on a newer ligpg* version, I got
gnupg2. And for some reason, gpg-agent is no longer working, I guess
it's caused by gpg2 installation? Anyhow, gpg2 works. With gpg-agent. So
I wanted to continue using caff with gpg2. Therefore, I configured
.caffrc to use gpg2.

What we get now:

$ caff 7C3AB9CFD230BD30DD009C591E7091B1F14A64A2 --debug
[DEBUG] gpg (GnuPG) 2.1
[DEBUG] Creating symlink /home/user/.caff/gnupghome/S.gpg-agent to 
/home/user/.gnupg/S.gpg-agent
[DEBUG] Creating symlink /home/user/.caff/gnupghome/S.dirmngr to 
/home/user/.gnupg/S.dirmngr
[DEBUG] Exporting key(s) 69740E5CB35FEC3C from your normal GnuPGHOME to 
/home/user/.caff/gnupghome
[DEBUG] gpg2 --batch --no-tty --trust-model=always --no-auto-check-trustdb 
--no-autostart ...
[DEBUG] stdin: <&=4, stdout: IO::Handle=GLOB(0x294bfa8)
[DEBUG] gpg2 --batch --no-tty --homedir /home/user/.caff/gnupghome --quiet 
--trust-model=always --no-auto-check-trustdb --no-autostart ...
[DEBUG] status: IO::Handle=GLOB(0x294bd20), stdout: >&=4, stdin: 5
[NOTICE] Fetching keys from pool.sks-keyservers.net, this may take a while...
[DEBUG] gpg2 --batch --no-tty --homedir /home/user/.caff/gnupghome 
--trust-model=always --keyserver=pool.sks-keyservers.net auto-key-retrieve 
--no-auto-check-trustdb --no-autostart ...
[DEBUG] stdin: <&=4, stdout: >&=4, status: IO::Handle=GLOB(0x3d9eb78)
[DEBUG] Imported 7C3AB9CFD230BD30DD009C591E7091B1F14A64A2 for 
7C3AB9CFD230BD30DD009C591E7091B1F14A64A2
gpg: key F14A64A2: "[User ID not found]" not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
[DEBUG] gpg2 --batch --no-tty --homedir /home/user/.caff/gnupghome 
--trust-model=always --with-fingerprint --with-colons --no-auto-check-trustdb 
--no-autostart ...
[DEBUG] stdin: <&=4, stdout: IO::Handle=GLOB(0x3ddcad0)
gpg: error reading key: Legacy key
[WARN] gpg2 exited with value 2
[WARN] No public keys found with list-key 
7C3AB9CFD230BD30DD009C591E7091B1F14A64A2 (note that caff uses its own keyring 
in /home/user/.caff/gnupghome)

The solution is removing .caff/gnupghome and let it replace it. This is
either a bug or your docs might point out that it needs to be deleted
after changing gpg version.

Regards,
Eduard.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages signing-party depends on:
ii  gnupg  1.4.19-5
ii  libc6  2.19-19
ii  libclass-methodmaker-perl  2.24-1
ii  libgnupg-interface-perl0.52-2
ii  libmailtools-perl  2.13-1
ii  libmime-tools-perl 5.505-1
ii  libnet-idn-encode-perl 2.202-1
ii  libterm-readkey-perl   2.33-1
ii  libtext-template-perl  1.46-1
ii  perl   5.20.2-6
ii  python 2.7.9-1
ii  qprint 1.1.dfsg.2-2

Versions of packages signing-party recommends:
ii  dialog 1.2-20150528-1
ii  exim4-daemon-light [mail-transport-agent]  4.86-3
ii  libgd-perl [libgd-gd2-perl]2.53-1+b1
ii  libpaper-utils 1.1.24+nmu4
ii  whiptail   0.52.18-1

Versions of packages signing-party suggests:
ii  fonts-droid1:4.4.4r2-7
ii  imagemagick8:6.8.9.9-5.1+b1
ii  mutt   1.5.23-3.1
pn  qrencode   
ii  texlive-font-utils 2015.20150823-1
ii  texlive-latex-extra2015.20150823-1
ii  texlive-latex-recommended  2015.20150823-1
pn  texlive-xetex  
pn  wipe   

-- no debconf information

-- 
 knopper wie ich mitbekommen habe hast du irgendwie etwas mit knoppix zu
tun, ..