Rejecting submission: Could not determine GPG uid

[vagrantc]

I've been manually submitting .buildinfo files for packages I've uploaded to Debian. But after recent updates to my key, it appears to no longer accept the signatures:

$ cat ../u-boot_2018.09+dfsg-1_amd64.buildinfo | curl -X PUT --max-time 30 --data-binary @- \ https://buildinfo.debian.net/api/submit
Rejecting submission: Could not determine GPG uid

My guess is either it has an outdated keyring, or does not support ed25519 signatures, or potentially both.

Thanks for maintaining buildinfo.debian.net!

Attached is the submitted .buildinfo (compressed, to make github happy). u-boot_2018.09+dfsg-1_amd64.buildinfo.0.gz

live well, vagrant

[lamby]

My guess is either it has an outdated keyring

buildinfo.debian.net does not check keyrings at all.

… , or does not support ed25519 signatures

Interesting. New key? Do old gnupgs not support ed25519?

[vagrantc]

|| My guess is either it has an outdated keyring | buildinfo.debian.net does not check keyrings at all.

So how does it verify that the GPG uid exists, since that data is in the public key material? Does it call out to a keyserver every time?

|| … , or does not support ed25519 signatures | Interesting. New key?

New signing subkey.

| Do old gnupgs not support ed25519?

Version 2.1.18 of gnupg in Debian stretch supports ed25519 (a.k.a. EDDSA). Is buildinfo.debian.net running an older release, or using gnupg1 ?

live well, vagrant

[lamby]

So how does it verify that the GPG uid exists

I'm curious why you think it does (or needs to). It just checks there is a valid UID. There are indeed calls to a keyserver but that is solely to turn an ugly hex UID into a name of sorts and (in addition) this is done entirely outside of the .buildinfo validation in an asynchronous queue job no less.

[dkg]

gnupg in debian stretch should be able to handle ed25519 verification without a problem.
however, if an openpgp certificate is malformed, the version of GnuPG in stretch currently rejects the whole cert, rather than salvaging the good bits (see https://bugs.debian.org/906545). Maybe that's the problem? I've proposed an update to GnuPG in stretch in https://bugs.debian.org/910398 that should resolve that issue, but the SRMs haven't decided about it yet.

[vagrantc]

The GnuPG updates landed in debian stretch's latest point release; I recently tried re-submitting the u-boot .buildinfo file again and still have the same issue. Not sure if it still needs to be updated, or if the issue isn't actually fixed in the newer GnuPG.

[dkg]

I used vagrant.key.gz (but gunzipped) locally on stretch, and tried it manually:

[GNUPG:] NEWSIG vagrant@debian.org
gpgv: Signature made Tue 11 Sep 2018 03:03:12 AM EDT
gpgv:                using EDDSA key 658073613BFCC5C7E2E45D45DC518FC87F9716AA
gpgv:                issuer "vagrant@debian.org"
[GNUPG:] KEY_CONSIDERED F0ADA5240891831165DF98EA7CFCD8CD257721E9 0
[GNUPG:] SIG_ID O4hLruA7fJQcw6prUf8BhwlDamA 2018-09-11 1536649392
[GNUPG:] KEY_CONSIDERED F0ADA5240891831165DF98EA7CFCD8CD257721E9 0
[GNUPG:] GOODSIG DC518FC87F9716AA Vagrant Cascadian <vagrant@aikidev.net>
gpgv: Good signature from "Vagrant Cascadian <vagrant@aikidev.net>"
gpgv:                 aka "Vagrant Cascadian <vagrant@debian.org>"
gpgv:                 aka "Vagrant Cascadian <vagrantc@aikidev.net>"
gpgv:                 aka "Vagrant Cascadian <vagrant@reproducible-builds.org>"
[GNUPG:] VALIDSIG 658073613BFCC5C7E2E45D45DC518FC87F9716AA 2018-09-11 1536649392 0 4 0 22 10 01 F0ADA5240891831165DF98EA7CFCD8CD257721E9
0 dkg@stretch:~$ 

and that all looks fine.

Then i tried manually looking at the file with a little python script test.py, inspired by bidb/api/utils.py:

#!/usr/bin/python
from debian import deb822
with open('u-boot_2018.09+dfsg-1_amd64.buildinfo.0') as f:
    a = f.read()
d = deb822.Deb822(a)
d.raw_text = a
g = d.get_gpg_info()
for x in ('VALIDSIG', 'NO_PUBKEY'):
   try:
     uid = g[x][0]
     break
   except (KeyError, IndexError):
     pass
print(uid)

and that prints a simple:

0 dkg@stretch:~$ python test.py
DC518FC87F9716AA
0 dkg@stretch:~$ 

(all on debian stretch, using python2)

so i'm perplexed as to what is going wrong on buildinfo.debian.net, and i can't replicate it.

[vagrantc]

I'm wondering if in bidb/api/utils.py:

• gpg_info = data.get_gpg_info()
• gpg_info = data.get_gpg_info(keyrings='/dev/null')

While the default value for keyrings is None in get_gpg_info, there appears to be a default set in deb822.GpgInfo.from_sequence:
:param keyrings: list of keyrings to use (default:
['/usr/share/keyrings/debian-keyring.gpg'])
... keyrings = keyrings or GPGV_DEFAULT_KEYRINGS

If that function is using the old keyring, and it's present, maybe the output is somehow unexpected?

Using dkg's example code (and tweaking to pass gpg_get_info(keyring=...), and just print), I also can't reproduce the issue, though, no matter what I feed it for the keyring.

Since december 1st, there have been at least 59 developer .buildinfo files impacted by this issue, which isn't a lot, compared to the thousands processed. A quick sampling of those suggests they are using non-rsa keys.

The contents of the .buildinfo file aren't the problem; I've re-signed several uploads with a gpg key using RSA and buildinfo.debian.net accepts them.

So I'm still as perplexed as ever...

[dkg]

do we have a local reproducer, one that doesn't depend on PUTting data to the https://buildinfo.debian.net/api/submit REST endpoint?