Bug#797712: failing with gpg2, error reading key: Legacy key
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
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
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
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
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
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
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. Uckouid [ 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
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
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
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, ..