Gabriel Brown
cb305f6662
OpenAI ships an official Linux RPM now, so the community wrapper goes away: `panama app chatgpt-desktop` built codex-desktop from the upstream macOS disk image and ran a local rebuild daemon to keep it current, and the official package comes from a repository that upgrades with everything else. The app file, the help example and the dock's pinned id all move over, and a migration replaces the build on machines that already have it -- official package on before the community one comes off, so a failure part-way still leaves an app. The install itself does not follow upstream's instructions. Those are "download this RPM and install it", and the RPM's own root scriptlet is what writes the repository file and drops the signing key into /etc/pki/rpm-gpg -- so root runs an unverified download and then learns from it what to trust. That is the shape the repository audit forbids: no network response is executed as root without a verified digest or signature first. OpenAI publishes no key and no fingerprint anywhere an install could fetch and check them, so the key is pinned here instead. setup/keys/ carries it and says where it came from, including the honest part -- this is trust established on first use and then held, not trust verified against the publisher. setup/lib/ chatgpt-package verifies that copy's fingerprint, installs it, and writes the repository with gpgcheck and repo_gpgcheck on before anything is installed, so dnf checks the metadata signature and the package signature itself. It is byte for byte the repository the scriptlet would have written, so nothing churns afterwards, and every later upgrade goes through the same key. Both callers use it; a verification failure skips ChatGPT rather than installing it anyway. The contract proves the pinned key is the key the library names, that a missing, unreadable or mismatched key writes nothing at all, that what is written actually turns the checks on, and that neither caller hands root a downloaded RPM. Claude-Session: https://claude.ai/code/session_017zzbtfnMLoYrB8WesqANFY
1.7 KiB
Pinned signing keys
A key lands here when a publisher signs what Panama installs but does not
publish the key, or its fingerprint, anywhere an install could fetch and check
them first. Pinning the key is what lets dnf verify a download before root
ever sees it.
Nothing here is a secret. These are public keys, and the reason to track them is that a changed one should be a merge request somebody reads, not a silent change of who is trusted.
RPM-GPG-KEY-chatgpt
| Fingerprint | 3BFA0E4AE8B8CC16A2D9BA684A3B4A566C4660E4 |
| User ID | Codex Linux Repository |
| Signs | the chatgpt package and the repository metadata at https://persistent.oaistatic.com/codex-app-prod/linux/rpm/$basearch |
| Used by | setup/lib/chatgpt-package |
Captured on 2026-08-27 from a machine where the official package had been
installed, at /etc/pki/rpm-gpg/RPM-GPG-KEY-chatgpt, where the package's own
root scriptlet writes it. It is the key that signed both the installed
chatgpt package and the live repodata/repomd.xml.asc.
Be honest about what that is worth: OpenAI's documented instructions (https://learn.chatgpt.com/docs/linux/linux-app) are to download an RPM and install it, and they publish no key URL and no fingerprint to compare against. So this is trust established on first use and then held, not trust verified against the publisher. Held is the part that matters -- from here every machine checks the same fingerprint, and a swapped download fails instead of installing.
To re-derive the fingerprint from the file:
gpg --show-keys --with-colons setup/keys/RPM-GPG-KEY-chatgpt \
| awk -F: '$1 == "fpr" { print $10; exit }'