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.

Hi,

It has nothing to do with signing-party anyway.

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

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?

Hallo,
* Guilhem Moulin [Tue, Sep 01 2015, 10:43:19PM]:

Uhm... see below.

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

$ 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 <amu@alum.mit.edu>
uid         [ unknown] Aaron M. Ucko <ucko@debian.org>
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.

Yeah, probably.

Regards,
Eduard.

Hi,

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.

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.

No it's not.

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,

Control: tag -1 moreinfo unreproducible

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.

Hallo,
* Guilhem Moulin [Wed, Sep 02 2015, 11:49:43PM]:

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.

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

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

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.

Hallo,
* Guilhem Moulin [Thu, Sep 03 2015, 11:46:42AM]:

;-) 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.000000000 +0200

Regards,
Eduard.

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,

  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?