I want to install FreeBSD 11.1. The announce points towards (https://www.freebsd.org/releases/11.1R/announce.html#availability) a set of PGP-signed files ( https://www.freebsd.org/releases/11.1R/signatures.html ) I want to verify the origin and integrity, thanks to PGP (GPG, gnupg), and downloaded https://www.freebsd.org/releases/11.1R/CHECKSUM.SHA512-FreeBSD-11.1-RELEASE-amd64-vm.asc, which is signed by 8D12403C2E6CAB086CF64DA3031458A5478FE293 I could not easily find this public key. It wasn't available through the announce, nor keyservers or in "The OpenPGP keys of the FreeBSD.org officers" ( https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pgpkeys.html ). I was able to find this key by asking for help in the Freenode 'freebsd' IRC-channel (thanks to the 'qbsd' user, who published it in a keyring https://pastebin.com/raw/D88Yzxig ). A serious search lets appear that the key is in https://www.freebsd.org/doc/pgpkeyring.txt (as a subkey of the A0B946A3 key), and this keyring is in the 'OpenPGP keys' article ( https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pgpkeys/ ) pointed in the handbook's Appendix D. ('OpenPGP Keys') but only in the "complete keyring", therefore one has to import this whole keyring or to explore it. AFAIK this is not a problem for anyone already using FreeBSD, who already has the keyring on his machine. IMHO this can be made more easy for the newcomer, maybe by having the announce ( https://www.freebsd.org/releases/11.1R/signatures.html ) pointing towards a file containing all signing keys. Moreover this signing subkey will soon expire (2017-09-25). I'm not sure that signing with a soon-to-be-expired key is reinsuring for a person who, in the near future, will download the file after the key expiration date. I also suggest that an OS documentation (Handbook, for the time being in "2.3.1. Prepare the Installation Media") may offer some hint about the usefulness of verifying any downloaded material thanks to a PGP-seal.
I'll talk to Glen when I see him at vBSDcon about moving from using a personal key to a release engineering team key (which doesn't appear to exist at the moment).
I just tried to verify a FreeBSD 11.1 download, but the signing key has expired.
Sorry for the delay, I forgot about this PR. The expiration has been updated, and the updates committed to the Handbook, which should be visible within a few hours.
A commit references this bug: Author: gjb Date: Wed Nov 1 16:51:12 UTC 2017 New revision: 51163 URL: https://svnweb.freebsd.org/changeset/doc/51163 Log: Update PGP subkey expiration. Reported by: Nat Makarevitch, Chris Brannon PR: 222044 Sponsored by: The FreeBSD Foundation Changes: head/share/pgpkeys/gjb.key
I would like to re-open this bug. The 12.0-RELEASE Checksum Signatures page: https://www.freebsd.org/releases/12.0R/signatures.html has this link for SHA256 signatures of i386: https://www.freebsd.org/releases/12.0R/CHECKSUM.SHA256-FreeBSD-12.0-RELEASE-i386.asc Here is my verification attempt: % gpg --verify CHECKSUM.SHA256-FreeBSD-12.0-RELEASE-i386.asc gpg: Signature made Fri Dec 7 14:25:42 2018 EST using RSA key ID 478FE293 gpg: Can't check signature: No public key % gpg --recv-key 478FE293 gpg: requesting key 478FE293 from hkp server pgpkeys.mit.edu gpgkeys: key 478FE293 not found on keyserver gpg: no valid OpenPGP data found. gpg: Total number processed: 0 The PGP pathfinder (https://pgp.cs.uu.nl) says: Can't find key 478fe293 in the strong set; is it on the surfnet.nl keyserver? Going back to the FreeBSD documentation, Appendix D of the handbook: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pgpkeys.html lists some keys, but not 478FE293. That page has a link for "the complete keyring": https://www.freebsd.org/doc/pgpkeyring.txt ...which does not appear to contain 478FE293 either. There is another page listing PGP keys, titled "OpenPGP keys": https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pgpkeys/ That lists various security role keys (not including 478FE293) and also includes the "complete keyring" link. I think at this point I am well beyond the steps that a regular user might be expected to take. Basically I think the release-signing key(s) should be all over any FreeBSD.org page talking about PGP keys, and also on any key server that people might be likely to use. Since I'm more dogged than the average user, I hunted around online; other people report a similar inability to find the key, including a StackExchange question which isn't really answered: https://unix.stackexchange.com/questions/346716/how-to-verify-freebsd-iso-download and a FreeBSD forum post which led to this PR I am seeking to re-open (what happened with the forum post was that somebody mailed the poster a key): https://forums.freebsd.org/threads/verifying-published-files-integrity-and-origin.62297/ Then I got mad and went back to the PGP Pathfinder message. It turns out that the key in question is *sort* *of* on surfnet.nl: 478FE293 is a sub-key of A0B946A3. I guess I might have been expected to find that out from pgpkeyring.txt... but while that file does list five sub-keys for A0B946A3 it does not list 478FE293. So here are my requests: 1. Please update pgpkeyring.txt. 2. Please institute a process for regularly updating pgpkeyring.txt. For example, the step in the release process that does signing could fail if the relevant sub-key isn't visible in pgpkeyring.txt. 3. Please document how users can validate FreeBSD releases. For example, the "12.0-RELEASE Checksum Signatures" page could say "These releases are signed by PGP key A0B946A3". I realize that might not be the right thing to put into the Handbook, since later releases might be signed by somebody else, but the Handbook pages could specify a procedure with more steps that could be applied to any release. Thanks!
Over to Glen for him to look at this issue.
Reopening based on current issue.
I cannot believe this issue is still open and not treated as urgent. Surely being able to easily verify the integrity is pretty important. Why haven't some kind of procedure been put in place yet?
I second the opinion that there should be some decent documentation in place that outlines how to validate that the downloaded files are indeed the ones from the official build in a cryptographic safe way. If there is one, I wasn't able to find it and am grateful for any pointers. I would also like to see this for the distribution packages (base.txz, ...), as I prefer them to provision jails. It is really strange this is issue is not more prominent.
I'm struggling with the same thing. I'm trying to find the public key. And I feel lost. This should be _easy_to_do_.
Here is how other operating systems deal with this topic: - OpenBSD: https://www.openbsd.org/faq/faq4.html#Download - ArchLinux: https://archlinux.org/download/ - Debian: https://www.debian.org/CD/verify (via https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/) As far as I can tell it is industry standard to provide a documentation on how to verify the deliverables right on the download and/or release pages.
I would like to re-raise the suggestion I made in comment #5, that the release-signing process include an automated check that the key being used appears in a keyring linked to from the appropriate web page, and that the signing process should fail if not. Or the process that posts a new release could do the check.
^Triage: commit bit was taken in for safekeeping.
Recently I read this amusing/scary/sad piece in Ars Technica: Secure Boot is completely broken on 200+ models from 5 big device makers Dan Goodin Ars Technica July 25, 2024 https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers Upon reflection, one thing that would have saved them would have been if the their release processes had included an automated check for "DO NOT SHIP" or "DO NOT TRUST" or maybe even "DO NOT ". With respect to this issue, which is admittedly much less dire, I still think the situation would be improved if the release process for FreeBSD included an automated check that the release signing key is present in a keyring which is present in the documentation.
(In reply to Dave Eckhardt from comment #14) I highly appreciate and second that opinion. And I also don't think this is a lot less dire here. In fact, 13.2-RELEASE provides a good argumentative underpinning as to why this is a really good idea. This release has been signed by a 1024 bit DSA (which is considered unsafe) key using SHA-1 (which is known to be broken). https://www.freebsd.org/releases/13.2R/signatures/ Back than I have created a security incident, which you can't view, because - security. Here is the link anyway: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274886 The bottom line was: "I don't think it's worth re-signing the 13.2 release hashes" In my opinion, if releases are signed, there should be a solid process in place, along with easy-to-follow and readily accessible documentation on how to validate these signatures.