Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad fingerprint at help.html, stale /version in linux release #191

Closed
darkk opened this issue Aug 23, 2016 · 1 comment
Closed

Bad fingerprint at help.html, stale /version in linux release #191

darkk opened this issue Aug 23, 2016 · 1 comment

Comments

@darkk
Copy link

darkk commented Aug 23, 2016

tl;dr version:

Key 4692719D, 2016-05-17:

Key 8453F85F, 2016-07-06:

Key 6091B1F8, 2016-08-09:

  • PGP PUBLIC KEY BLOCK at /help.html
  • keyid in verification example at /help.html
  • actual key used to sign linux release on 2016-08-21

/help.html webpage mentioned fingerptint 94B8 4193 A00C FA50 F4DC 7475 8457 F623 8453 F85F, but the key embedded in the webpage has fingerprint FA21 CD53 6312 FADF 9B5D D804 AB26 6CB7 6091 B1F8.

Also, keyid 6091B1F8 matches the key, but does not match announced fingerprint.

Also, the signature for linux blob was made with key 6091B1F8. The blob has /version file saying it's 1.3.3, but zip file stores mtime metadata and mtime suggests it's 3.2.06, as it was created on 2016-08-21, gpg signature suggests same mtime.

$ gpg --verify Cryptocat.zip.asc 
gpg: assuming signed data in `Cryptocat.zip'
gpg: Signature made Sun 21 Aug 2016 06:20:18 PM MSK
gpg:                using RSA key AB266CB76091B1F8
gpg: Good signature from "Nadim Kobeissi <nadim@nadim.computer>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: FA21 CD53 6312 FADF 9B5D  D804 AB26 6CB7 6091 B1F8

So the key and keyid seem to be correct, and fingerprint seems to be wrong. But 8453 F85F is mentioned in #170 and release notes as a correct key.

Also, please consider switching to keyid-format long in documentation as 32bit keyids are ambiguous nowadays due to https://evil32.com/

@nadimkobeissi
Copy link
Contributor

This was already fixed in c0d5a68.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants