Post #2070595

2026-04-30 21:41 UTC

For that reason, it will be revoked, and our 150.0.1-1 releases have all been signed with a newly generated subkey. As only the subkey (0x43A83048DF19C075A55266A78A74EAAF89C17944) had been exposed (only it is available to the CI), our main key itself (0x662E3CDD6FE329002D0CA5BB40339DD82B12EF16) could not have been compromised by this. The new signing subkey's fingerprint is 0x230FE8E090E0ECBF2D925560915585A1C36690B1. 2/5

Replies (3)

@librewolf@chaos.social 2026-04-30 21:42

It only being a subkey means that verification should just go as smoothly as usual with most installation methods. Unfortunately, if using AppImageUpdate to update the AppImage, it will show an error about the key having changed. This is to be expected, and a manual download of the AppImage must be done. 3/5 Edit: looks like I messed up making a proper thread, sorry! Here are 4/5 and 5/5: https://chaos.social/@librewolf/116495833307059758 https://chaos.social/@librewolf/116495834672105320

Open ##2070596
@baltakatei@twit.social 2026-04-30 22:22

@librewolf Is there a static security page with these fingerprints that I can load into http://web.archive.org/save for future reference? I like to track notable public keys and key changes are important events. Also, helps with justifying edits to #Wikidata and #Wikipedia to note public keys.

Open ##2070597
@isf@muenchen.social 2026-05-20 21:00

@librewolf@chaos.social It would be a really great thing if you could remove the revoked subkey from the provided public key. Because there are distros (e.g. EL9) which are very picky about that and strictly refuse any importing of a pubkey containing a revoked sub key.

Open ##3223681