| 5 Mar 2025 |
 Picnoir | If I understand your categorization correctly, you'd put FODs in the "output" category? | 09:04:08 |
 Robert Hensing (roberth) | yes. They're also the current most frequent example where "first" is a thing, because many FODs can produce the same output path | 09:05:10 |
| Picnoir | Shouldn't there be a third category for FODs? They're resulting from the builder but are output-addressed. | 09:05:21 |
| Picnoir | Yeah | 09:05:23 |
| Picnoir | And most importantly: can be poisoned. | 09:05:29 |
| Robert Hensing (roberth) | It applies to all CA outputs, where FOD is a special case of CA as it can be implemented without rewriting any hashes | 09:06:14 |
| Robert Hensing (roberth) | (the deriver firstness thing I mean) | 09:06:59 |
| Robert Hensing (roberth) | not sure what you mean with poisoning? | 09:07:07 |
| Robert Hensing (roberth) | btw input addressing might not have the uniqueness property that it currently sort of has, with https://github.com/NixOS/nix/issues/10780 | 09:11:24 |
| Picnoir |
- You upload some sort of payload in a store (be it local or remote) to a certain output hash.
- You push a fetcher derivation trying to fetch from a certain URL having the CA of step 1 (wrong ca).
- The builder uses the cached FOD in the local/remote store instead of trying to verify the FOD.
Agreed, this is more of an UX-like posoning. Also agreed, it's CA-specific, not FOD specific.
What I'm trying to say, is that CA and non CA derivations are behaving quite differently on the build graph. I'd be nice to have a way to distinguish those from the validpath boundary.
| 09:13:21 |
| Picnoir | I'm not super familiar with nix CA, that's why I was focussing on FODs :) | 09:13:45 |
| Picnoir | *
- You upload some sort of payload in a store (be it local or remote) to a certain output hash.
- You push a fetcher derivation trying to fetch from a certain URL having the CA of step 1 (that does not necessarily reflect the ca you'd get fetching the url).
- The builder uses the cached FOD in the local/remote store instead of trying to verify the FOD.
Agreed, this is more of an UX-like posoning. Also agreed, it's CA-specific, not FOD specific.
What I'm trying to say, is that CA and non CA derivations are behaving quite differently on the build graph. I'd be nice to have a way to distinguish those from the validpath boundary.
| 09:14:59 |
| Robert Hensing (roberth) | John Ericson: I've suggested to treat the Nixpkgs "fix" for the CA placeholder issue (no storedir prefix) as a workaround as ca-derivations is experimental https://github.com/NixOS/nixpkgs/pull/386774#pullrequestreview-2660479310 | 09:27:53 |
| Robert Hensing (roberth) | See https://github.com/NixOS/nix/issues/12577 for avoidable confusion | 09:31:20 |
 emily | isn't /. + "/1121rp0gvr1qya7hvy925g5kjwg66acz6sn1ra1hca09f1z5dsab" problematic in the same way as being able to construct arbitrary store path values? | 14:26:10 |
 John Ericson | @roberthensing:matrix.org: haven't read it yet (cause packing) but I realized that output names for dyn drv are in fact statically known! | 16:06:02 |
| John Ericson | The drv name & output spec name -> output store path name function | 16:06:22 |
| John Ericson | You can just do it recursively down the deriving path | 16:06:35 |
| John Ericson | It's funny I didn't realize this before, because in a way I did: I was always frustrated making dyn drv examples that the "name felt so predetermined' | 16:07:14 |
| John Ericson | Well, lol, it was exactly pre-determined! | 16:07:33 |
| Robert Hensing (roberth) | Nice. Don't be late because I nerd sniped you! | 16:08:00 |
| John Ericson | Based on this, I feel like both types of placeholders could look exactly like store paths, except for using a different hash character set to very subtly distinguish them | 16:08:25 |
| John Ericson | I might be a little worried about that confusing humans, hah, who just glance at it | 16:08:55 |
| John Ericson | But it would be great for code in Nixpkgs that wants to look for name parts and and the store dir | 16:09:29 |
| Robert Hensing (roberth) | Canonical JSON looks kinda good. Canonical, sorted, no floats. Strings are bytes, so not technically JSON. RFC 8785 is complicated and does not allow non-Unicode bytes | 16:31:41 |
| emily | please don't use canonicalized JSON formats | 16:42:10 |
| emily | people WILL use something less rigid and only find out years down the line when it's a huge headache | 16:42:25 |
| emily | pick a format that's rigid by design or at least has a canonical format rigidly specified in the same spec rather than being something people have made 100 canonical versions of | 16:42:54 |
| emily | it's a huge footgun, everyone who uses JSON in a cryptographic context gets bitten by this eventually. Matrix included iirc :) | 16:43:17 |
| Robert Hensing (roberth) | hmm ok. Something human readable would be great (and something not ATerm) | 16:45:17 |
