$ gpg --allow-non-selfsigned-uid --no-default-keyring --keyring /tmp/tmp.s7YEIIZX --import /tmp/tmp.oVtOGme1 ... gpg: invalid armor header: mQINBF+5ojQBEADSqQjD4h1lOwAGgmz4dK0Zf4JkoJCpQ7jw2B5jigNySdKf1rQN\n gpg: CRC error; DDCBB0 - 42D3D7 gpg: [don't know]: invalid packet (ctb=48) gpg: read_block: read error: invalid packet gpg: import from `/tmp/tmp.oVtOGme1' failed: invalid keyring gpg: Total number processed: 263 gpg: imported: 263 (RSA: 166) gpg: no ultimately trusted keys found
The problem is a missing empty line before
mQINBF+5ojQBEADSqQjD4h1lOwAGgmz4dK0Zf4JkoJCpQ7jw2B5jigNySdKf1rQN(currently at line 49955).
Please fix this asap, we are relying on that file for automated release ISO signature validation.
As a side note, the hosting of that file is also sort of broken. The download breaks frequently like in the following example (from today):
$ fetch -o /tmp/tmp.oVtOGme1 -- 'https://docs.freebsd.org/pgpkeys/pgpkeys.txt' /tmp/tmp.oVtOGme1 87% of 5481 kB 1259 kBps 04s fetch: /tmp/tmp.oVtOGme1 appears to be truncated: 4905771/5612792 bytes
As another side note: Why are you not using some sane key to sign the releases (like the security officer key) that would allow you to validate an ISO without trusting a couple hundred keys (or jumping through yet another set of hoops for extracting that very particular key)? And while we are at it: why isn't there a sane and well documented process for this (I'm not even talking tools...)? After all, we have the year 2021. I would expect something that doesn't feel homegrown and severly outdated. And I certainly don't want to download and validate some release ISO to get hold of a trustworthy MANIFEST just to validate a base.txz.
It also doesn't help that the checksum files and the keyring are renamed and moved at will on the website without any notice. This way you also break the processes other people build in lack of an official one. At least give us an HTTP redirect!