| 24 Aug 2023 |
 BMG | It seems to be fetching the narinfo from the remote, adding the signature and doing a PUT back. Slight window for issues there but I imagine it's a small one | 15:24:02 |
| BMG | unlikely to be adding 2 signatures at once from different sources | 15:24:22 |
 @linus:schreibt.jetzt | yeah I'm not sure it's possible to improve that, at least with the HTTP API | 15:24:53 |
| @linus:schreibt.jetzt | wait no | 15:24:58 |
| @linus:schreibt.jetzt | there are headers for conditional update, aren't there? | 15:25:10 |
| BMG | i was just about to check for that :) | 15:25:18 |
| BMG | I remember e-tags but it's been a while since i looked into this | 15:25:42 |
| BMG | Gonna capture what nix is doing to see if it's setting anything | 15:25:52 |
| @linus:schreibt.jetzt | at the same time, I think it's fair enough to just not implement it | 15:25:55 |
| BMG | Can confirm, Nix isn't setting anything special on the request | 15:26:58 |
| BMG | A PATCH would technically be the 'correct' way to do this I guess | 15:27:29 |
| BMG | Or it looks like ETag and If-Match is how you can prevent this https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag#avoiding_mid-air_collisions | 15:28:56 |
| BMG | Nix client would refresh and try again | 15:29:34 |
| @linus:schreibt.jetzt | I think generally something like attic is a better approach to a binary cache anyway | 15:29:51 |
| BMG | attic is using it's own client right? | 15:31:25 |
| BMG | instead of the http interface | 15:31:30 |
| @linus:schreibt.jetzt | it can serve Nix's protocol read-only as well | 15:31:44 |
| BMG | Makes sense now why Domen did it aswell | 15:32:00 |
| BMG | the http interface is fine for read | 15:32:11 |
| BMG | not that great for the writes | 15:32:18 |
| BMG | For context, I'm playing around with my own cache implementation which is why I'm interested | 15:33:05 |
| @linus:schreibt.jetzt | one thing I'd like to have in Attic is the ability to have signatures from the client in addition to server-managed signing keys | 15:34:12 |
| BMG | Have it merge on upload? | 15:34:34 |
| @linus:schreibt.jetzt | well currently attic just stores a single signature for each narinfo (which is a database table entry, not an actual file), and that signature is generated by the server at upload time | 15:36:02 |
| @linus:schreibt.jetzt | but it means that you have to trust the server much more than if the client could provide its own signatures | 15:36:24 |
| BMG | makes sense, also what happens with key rotation on the server | 15:37:06 |
| @linus:schreibt.jetzt | key rotation is generally a tricky topic with nix https://github.com/NixOS/rfcs/pull/149 | 15:37:58 |
 Zhaofeng Li | In reply to @linus:schreibt.jetzt
well currently attic just stores a single signature for each narinfo (which is a database table entry, not an actual file), and that signature is generated by the server at upload time The signature is generated at download time using the the per-cache private key managed by the server. It does store client-supplied signatures in the database but they aren't exposed at the moment. I wrote a bit more here: https://github.com/zhaofengli/attic/issues/80#issuecomment-1684347741
(oh right, forgot to respond)
| 15:40:33 |
| Zhaofeng Li | So we can easily have client-managed signatures now by changing how narinfo is generated (need to fix serialization for multiple signatures), but I'd prefer to have a complete story UX-wise (the client should be able to automatically sign on upload) | 15:42:27 |
| Zhaofeng Li | In reply to @brian:bmcgee.ie
makes sense, also what happens with key rotation on the server You currently can rotate the server-managed key with attic cache configure --regenerate-keypair, but all clients who download need to reconfigure their trusted public keys | 15:44:35 |
