Closed diabonas closed 2 years ago
The two of us work for the same company on the same team (and you can verify this) and I'm strongly connected in the PGP web - a trust path does exist. A cross-signature is logistically difficult to manage during the ongoing pandemic, but we're working on it.
The two of us work for the same company on the same team (and you can verify this) [...]
Unfortunately I cannot cryptographically verify this in the same way I can verify a PGP signature: the idea of having the signature in the first place is being able to make sure that nobody else is able to fake a release, even if they e.g. somehow got access to the GitHub organisation or the Red Hat website.
[...] and I'm strongly connected in the PGP web - a trust path does exist.
That is probably true, but a very weak guarantee, because it might prove your identity, but not a direct connection between the two of you. A direct cross-signature would make me much more confident that this change was intentional and nothing suspicious is going on.
A cross-signature is logistically difficult to manage during the ongoing pandemic, but we're working on it.
I completely understand that obtaining a cross-signature can prove to be difficult at the moment. However, a signed message by @vathpela confirming the new release maintainer as suggested above should be doable, since it does not require any form of physical contact.
I apologise for the inconvenience caused: I am really not trying to make you jump through red tape just for the sake of it, I am genuinely concerned about the chain of trust for such a security critical trust anchor as shim. @vathpela even goes to the length of posting signed warrant canaries regarding his involvement with Secure Boot, so an unannounced change in the release signing key is not something I can take lightly. I am not accusing you of any maliciousness, but I want to make sure to apply all the due diligence I possibly can.
Well, then you're just going to have to be more patient then because it's going to take a bit. (If you think about it, even your signed statement requires physical verification - my key needs to be positively identified, after all.)
Well, then you're just going to have to be more patient then because it's going to take a bit.
Sure, the Arch Linux shim package will be held at version 15.4 until this is resolved anyway. Do you have an approximate time frame for this?
Again, I urgently want to suggest documenting the valid release signing keys somewhere in the repository: this issue could have been avoided if you and your PGP key had been added e.g. to a MAINTAINERS
file before 15.5-rc2, which is still signed by @vathpela, was cut.
(If you think about it, even your signed statement requires physical verification - my key needs to be positively identified, after all.)
A signed statement asserting that the maintainer has changed (even while admitting their key ID has not been physically verified yet) would certainly be better than the completely broken chain of trust we have at the moment. But yes, that is something I would have appreciated to be figured out before cutting a release which is effectively unusable in its current state.
We have now cross-signed.
Awesome, thank you very much! I confirm that I was able to obtain and verify both cross-signatures (from keyserver.ubuntu.com) and have therefore updated the Arch package to the latest version 15.5.
While trying to package the latest release 15.5 for Arch Linux, I noticed that it is signed by a new PGP key belonging to @frozencemetery, key ID:
039A9CEA19DE9508C36875AA2532F9176A95A442
. Previous releases up to 15.5-rc2 were however signed by @vathpela, key ID:B00B48BC731AA8840FED9FB0EED266B70F4FEF10
. I couldn't find a signature for the new key by the old key to verify the relation between the two keys in order to make sure nothing suspicious is going on.Could @vathpela cross-sign @frozencemetery's key so that it can be used to verify the authenticity of the new release, please? As an alternative, a message signed by @vathpela documenting the new release key would be fine as well.
In future it might be helpful to document the PGP keys trusted to sign releases in the repository, e.g. in a
MAINTAINERS
file: as long as you wait for one (pre-)release until new maintainers start signing new releases, this would establish a chain of trust via the signed release tag of the previous release.