LGTM 👍

👎 I don't like ad-hoc uses like this. Maybe a setup hook would be better?

A setup hook might be a good idea for signed tarballs. In this case, the tarball itself isn't signed but contains a binary and a signature file. I don't see a good generic solution for this.

Not in this case, but in case of signed tarbals it would make sense to extend fetchurl to also allow checking for signatures, eg:

fetchurl {
  url = "....";
  sha256 = "....";
  public_key = ./1password.pub.key;
}

Another question: should we be committing keys to the repo or fetching them? A large number of public keys may take up a decent amount of space over time?

In the long run it would be better to fetch and cache them like we do with sources or patches.
But that requires a stable download URL plus an additional step of verifying the key's fingerprint.
Probably leads to an abstraction like fetchpubkey ...

Another question: should we be committing keys to the repo or fetching them? A large number of public keys may take up a decent amount of space over time?

Yes this is definitely a good concern. Also what security does the signature add that the sha256 doesn't have? For both we have to trust that the signature in Nixpkgs is valid & not been tampered with. We should just tell people to verify the signature before updating the sha256 hash in pull requests updating 1password.

These things always come down to "you gotta trust something in the beginning".
Still better than trusting a sha256 on a TOFU basis because the public keys, as opposed to sha256 hashes, are typically long-term and rarely change. Makes it more likely that attacks will be spotted.

Using this as an example to create helpers for verifying signed code. I plan to implement a setup hook with some functions for signature verification next.

continued in #43233, which aims at a more general solution