firefox-overlay, impurity, and a missing link in GPG verification?

[colemickens]

I'm doing a cleanup of flake-firefox-nightly.

I'm very close to be able to support all variants on x86 + aarch64... but...

the overlay is still very liberal in its use of impure fetching.

Specifically while Nightly fetches a signature file and a checksum of that file, for "releases" (beta/stable) it seems that a link out to a GPG key is given.... and then impurely fetched.

It also just presents a more serious question of how this is meant to be used. ... If a public key is not burned into the metadata, a key grip isn't given, then it seems like this is still moving most of the integrity check to.... DNS/TLS/public CAs.

[colemickens]

Thread renamed to reflect further thoughts as I wrote it out. I feel like the toplevel version info should really, really include the keygrip at the very least of the key that it links to. More ideally it would be the checksum though, so I can juts fix this the way I've fixed it for Nightly.

[colemickens]

Looking at this again, I see now that the key itself is pinned, and the checksums are stored next to a signature file that can be verified with the key. Which seems fine, but is still unfortunate for Nix, I'd have to pre-cache the checksum+checksumSig hashes for each variant. :/

[nbp]

4 things are downloaded:

• the gpg key (checked using hard coded checksum)
• the firefox_versions.json file. (https only)
• the checksum file. [beta / release] (verified using the gpg key) [nightly] (https only)
• the firefox binary. [beta / release] (verified using the verified checksum) [nightly] (verified using the gpg key)

Despite our best effort, this would remain impure as the sha of the checksum file is unknown.

I am definitely in favor of adding whatever script is needed to generate the equivalent of a lock file to be committed to another branch of this repository, in order to hard-code the latest checksums of the day, as long as this does not pollute the history of the repository.

Pollution of the history of the repository, is from my point of view a security issue, as someone who might want to review the changes might miss the changes which are altering the logic.

Note: This repository will migrate soon.