[WIP] 1password: check binary code signature during build

[xeji]

Motivation for this change

Check binary code signatures during checkPhase using upstream code signing key.
I don't use 1password myself (it's an unfree, commercial service) but the discussion in #42539 prompted me to try this because code signing is a topic that needs more attention in nixpkgs anyway.

cc @jb55 @marsam for testing.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Fits CONTRIBUTING.md.

---

[jb55]

Check binary code signatures during `checkPhase` using upstream code signing key.

Tested ACK, seems to work. nice!

[jb55]

👍

[marsam]

LGTM 👍

[matthewbauer]

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

[xeji]

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.

[garbas]

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;
}

[jb55]

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?

[xeji]

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 ...

[matthewbauer]

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.

[xeji]

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.

[jb55]

Another thing that would be nice: I'm currently in the process of upgrading the trezor bridge: the release tagged commit is signed but the hash I'm getting from fetchFromGitHub is not. I'm trying to re-create the hash with nix-hash without any luck. It would be cool if there was a way to provide a public key to fetchgit, which would verify the commit with git-verify-commit after checkout.

[xeji]

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.

[jb55]

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.

awesome!

[xeji]

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