| 23 Feb 2024 |
 K900 | I'm pretty sure I got it right | 15:50:35 |
| K900 | But I don't have a Hydra to test on | 15:50:43 |
| K900 | But I did copy the urlencode incantation | 15:51:01 |
| K900 | * But I did copy the urlencode incantation from another place in Hydra where it presumably works | 15:51:09 |
|  @fedx:matrix.org left the room. | 16:46:46 |
| 26 Feb 2024 |
|  martiert joined the room. | 06:53:11 |
| martiert | I have a hydra server running. It's building packages correctly, and I can reach it. But for some reason I can't verify the signature of the packages on it. I have added the public key to the nix.settings.trusted-public-keys and set nix.extraOptions = "secret-key-files = /path/to/my/secret/key"; Is there a way to manually check the signature on the packages served by hydra? It's using a local store to serve the packages, not a BinaryCacheStore. | 06:59:36 |
 tomberek | "nix path-info --json" can show you the signatures. How are you signing the packages right now in Hydra? | 11:32:49 |
| martiert | I just set nix.extraOptions = "secret-key-files ...";, which as far as I understood should be what hydra uses when we just the the local store? | 12:07:45 |
| martiert | or am I completely misunderstanding this part? | 12:21:59 |
| martiert | hmmm.. Guess I have missunderstood, as stuff is not signed | 12:23:22 |
| tomberek | That would apply only for built paths (not substituted) and local (not remote builders). You may be looking for the hydra store_uri option with a query parameter to specify the key. | 12:33:44 |
| martiert | ack, thanks. I'll look at that | 13:04:03 |
| martiert | is it valid to say store_uri = file:///nix/store?secret-key=/my/secret/key? | 13:07:10 |
| tomberek | Yes, but if memory serves, you may want "local?secret-key..." so that it talks to the daemon. | 18:04:49 |
| martiert | store_uri = "local?secret-key=..." gives me error: don't know how to open Nix store | 18:15:38 |
| martiert | should it be localhost, or maybe s3://localhost ? | 18:15:56 |
| martiert | think I found it out. Needs to be store_uri = daemon?secret_key=... And without quoting the URI like I did | 18:29:33 |
| tomberek | There we go. Possible that "auto" can work. | 18:36:44 |
| tomberek | The idea is that that store setting should ensure the packages are all signed as they are created. | 18:37:17 |
| martiert | yeah, so packages already created would not be signed then? And I would potentially need to manually sign them? | 18:37:56 |
| martiert | hmmm... for some reason it's still failing to verify. I tried manually signing a package, and I see it is signed, but not with a key in the trusted-public-keys, though my key is in there. | 18:39:57 |
| martiert | I made the key with nix key generate-secret --key-name hydra.localdomain > secret_keyfile, and the public key using cat secret_keyfile | nix key convert-secret-to-public | 18:44:31 |
| martiert | though I generated them on another machine, and put them on the hydra server using agenix, but that shouldn't matter I think | 18:45:07 |
| martiert | hmmm... I do see it's signed if I query the path directly on the hydra server, but there is no signature if I do curl http://hydra.localdomain/<somehash>.narinfo Can I do anything to retroactively sign a store path? | 18:58:24 |
| tomberek | Yes, nix store sign can help you here. There are some UX issues with signing. I wrote some of that down here: https://github.com/NixOS/nix/issues/6960#issuecomment-1383352182 | 19:01:17 |
| martiert | I did try nix store sign --recursive --key-file /run/agenix/my_keyfile /nix/store/<hash>-linux-6.7.3, which is signed if I check it locally, but not if I try to query it from remote. So I guess I should use nix copy --to "daemon?secret-key=/run/agenix/my_keyfile"(?) but that looks for a flake.nix | 19:09:56 |
| martiert | which fails due to the secret-key option not being recognized. | 19:36:45 |
| martiert | Guess the easiest is to just wait for the next update that runs the builds again and just let hydra fix it for me :) | 19:47:52 |
| K900 | https://github.com/NixOS/hydra/pull/1364 should be good to merge now | 19:49:32 |
