3.0.7: signature key-id 763629FEC8788FC35128B5F6EE029D1E5EB40300 not found

[dvzrv]

Hi!

I'm currently trying to build 3.0.7 as a package for Arch Linux. It seems a new key was used for signing this release, but this is not mentioned in the release notes, nor can the key be found on any keyserver yet.

Please sign the new key 763629FEC8788FC35128B5F6EE029D1E5EB40300 with the old key 2CF6E0B51AAF73F09B1C21174D1DA68C88710E60 and upload the new key (plus signature) to the keyservers, so a chain of trust can be established.
In the current situation I feel not comfortable packaging this version.

In case you want to make sure that the key ends up on (all) key servers, you can use this script:
https://paste.xinu.at/axX1B9w/

[Harmon758]

According to 6b8e7b7 and 7b74a5b, this was due to @Byron's hardware situation.

[Byron]

Indeed! I will fix it as soon as I can, which is when the travel ban in China is lifted.

[Byron]

Version 3.1.1 was just released, signed with the known signature.

I plan to establish a chain of trust with new keys in May to allow CI to produces packages automatically in future, thus removing the dependency on me or my key.

[dvzrv]

Eh... sorry, but you are still referring to EE029D1E5EB40300, which is not known and not even available on the key servers....
Please don't spread false information...

The only known key so far has been 2CF6E0B51AAF73F09B1C21174D1DA68C88710E60 and until you signed 763629FEC8788FC35128B5F6EE029D1E5EB40300 I will not release.

[Byron]

I don't know where the idea of me intentionally spreading false information is coming from, especially given the track record of this project with keys and their (mis)management. Often people are just making mistakes.

Thanks for pointing out which key is the right one - now that I have two computers here, one with USB-C and my gpg configuration, and another one without gpg configuration but USB-A support, I should finally be able to add one and one together and sign with 2CF6E0B51AAF73F09B1C21174D1DA68C88710E60.

Eventually I will manage to get it right.

[Byron]

Ok, I tried and I failed with

error: gpg failed to sign the data

I have no idea what kind of massaging it wants to accept the configuration and the plugged-in USB-A key, and I think it's best to save the time to find out and postpone this to May. Then I will be back home with access to all the neat gadgets that allow me to use a USB-A key on a computer with USB-C ports only, but with a provably working gpg configuration.

Apologies for the inconvenience this false alert may have caused, life is complicated sometimes :D

[dvzrv]

Often people are just making mistakes.

Sorry, I did not mean that in an offensive way. It just got me running in a wrong direction this morning.

Ok, I tried and I failed with

error: gpg failed to sign the data

What were you trying to do?
If you want to sign the tarball with your key (the one that was initially used):

gpg --detach-sign -u '2CF6E0B51AAF73F09B1C21174D1DA68C88710E60' -o <package>.asc <package>

If you want to sign the new key 763629FEC8788FC35128B5F6EE029D1E5EB40300, you can use something like pius or signing-party.

[Byron]

No worries, all good! Please note that GitPython v3.1.2 was just released with the known signature.

Regarding the failure - by now I don't even know what I tried to do there, but recall that all it presented was this nondescript error message. For now I am able to sign using the common keys and maybe one day I will manage to sign the new key (7636…) with the old one (2CF6…) and publish this to the key servers.

Shouldn't be too hard, and it's certainly worth it to make this system more robust. Your suggestions on how to achieve this are highly appreciated as well in case you want to share useful tips and resources on how to do this properly.
Thank you

[dvzrv]

Closing in favor of #1055