Mark Phippard wrote:
> Julian Foad wrote:
>> Me too. It appears I need to update my configured keyserver. Then
>> maybe fetch keys and then maybe the checking will work. That's based
>> on, so far, finding that checking existing keys fails due to
>> unreachable key server, and then reading [...]
OK, unpicking what I was doing: I started from a script I wrote years
ago that goes through the steps of fetching, testing, signing etc. It
checks existing sigs before signing my sig. It was erroring out at the
checking your sig (which was the only sig in the releases' *.asc files,
at that time):
$ tools/dist/release.py --target=. check-sigs 1.10.8
INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.bz2.asc
BAD SIGNATURE: Key 1 in ./subversion-1.10.8.tar.bz2.asc
key id: C4416167349A3BCB
ERROR!
So I first tried refreshing my local GPG keyring, and hit the obsolete
keyserver problem I mentioned. I fixed that by changing the keyserver
entry in my ~/.gnupg/gpg.conf to say "keyserver
hkp://keyserver.ubuntu.com". Then "gpg --refresh-keys" succesfully
fetched updates including your new key.
Then the checking got further but still errored out:
$ tools/dist/release.py --target=. check-sigs 1.10.8
INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.bz2.asc
INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.gz.asc
INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.zip.asc
Traceback (most recent call last):
File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line
1916, in <module>
main()
File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line
1912, in main
args.func(args)
File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line
1458, in check_sigs
output = get_siginfo(args)
File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line
1420, in get_siginfo
formatter = PUBLIC_KEY_ALGORITHMS[keytype]
KeyError: 22
I took a quick look at the source but couldn't quickly figure it out. I
see now (quoted below) that your new key is a newer EC type; maybe that
is why. But keytype 22 isn't listed in the table referenced from a
source code comment and I don't know where to turn next.
Then I realised that checking existing keys need not block me from
adding my own, and so I proceeded with that.
> [...]
> 1. The KEYS file is from the script that was shared.
> 2. I had to create a new GPG key. I noticed it gave me one of the
> newer elliptic curve keys. Maybe not all versions of OpenPGP can
> handle these?
> 3. I uploaded it to the MIT keyserver as per something I read in the
> ASF committer docs ...
> Actually looking at history I did this: gpg --send-key
> EC25FCC105618D04ADB43429C4416167349A3BCB
> 4. I updated my fingerprint in ASF LDAP
>
> Since I just created this key a couple weeks ago if it is better that
> I generate a new key, re-sign the release and upload new signatures
> just let me know what to do.
At this point I don't have reason to suspect your key is bad, more
likely the scripting and/or my setup needs some update. But I don't
expect to spend more effort on this unless it becomes a blocker for something.
Thanks,
- Julian
