On Mon, Apr 4, 2022 at 4:46 AM Julian Foad <julianf...@apache.org> wrote:
> 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. FWIW Mark's key did verify successfully for me (good signature but can't verify web of trust because it hasn't been cross-signed). I am using a relatively new build of GPG. Away from my computer so I can't show the exact output or version info at the moment. Cheers, Nathan
