 | Nix Hackers | 902 Members |
| For people hacking on the Nix package manager itself | 190 Servers |
| Nix Hackers | 902 Members |
| For people hacking on the Nix package manager itself | 190 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Mar 2025 | ||
 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 |
| emily | human-readable can actually be a drawback for formats specifically designed to be non-malleable, precisely because they invite opening in a text editor and appending some keys in whatever order. fwiw, https://preserves.dev/ is well-designed, has a superset of JSON types, and has both a textual format and a binary format with a rigidly-defined canonical representation for the latter. however it's also a bit obscure and won't have as wide library support as alternatives so I can understand not going with it. the Spritely/Agoric/Cap'n Proto standardization effort OCapN uses it as Syrup, which is a separate canonical-but-made-up-of-printable-characters serialization of it https://github.com/ocapn/syrup#pseudo-specification. more well-known alternatives:
also, if you don't actually need a flexible/extensible format, defining your own very simple rigid serialization isn't a sin when you want cryptographic canonicity. (just make sure it's actually non-ambiguous and preferably can't be corrupted into another valid message by truncation, especially if you might be concatenating multiple messages.) | 17:00:57 |
| emily | (total digression but Preserves is also used in the https://syndicate-lang.org/ ecosystem which I suspect John Ericson might find interesting) | 17:03:05 |
| emily | (the Preserves textual format is also a superset of JSON, so in terms of being able to ingest things in a familiar format to then canonicalize it works well. but again many understandable reasons to pick something else, just giving an overview of the space as I see it) | 17:04:33 |
| Robert Hensing (roberth) | John Ericson: did we have an issue on this topic yet? Couldn't find one | 17:06:35 |
| John Ericson | @roberthensing:matrix.org: for new drv format? | 17:24:42 |
| John Ericson | Not actually sure | 17:24:54 |
| John Ericson | Also FYI https://github.com/facebook/buck2/issues/866 | 17:25:21 |
| John Ericson | I sent to @edef1c too | 17:27:02 |
 puck | In reply to @roberthensing:matrix.org builtins.placeholder has the same "issue", though i like them not being /nix/store-prefixed because it disambiguates that their format is unstable | 17:31:38 |
| Robert Hensing (roberth) | That one isn't experimental, so we'd need a very very good reason to change that anyway | 17:33:35 |
| emily | I don't suppose Nix strings support NUL bytes in them so that we could properly separate the namespace from actual filesystem paths? in the same way abstract Unix sockets do | 17:33:47 |
| Robert Hensing (roberth) | Also isn't user-handled as much as outputs are | 17:34:04 |
| Robert Hensing (roberth) | Evaluator strings are C strings. This could be changed to something with a length, but we're not in a hurry. I guess one of those separator control characters could serve the same role, but I feel that it'd be weird to do any of that (regardless of choice of byte value) | 17:35:50 |
| emily | NUL is the only byte that is actually guaranteed to not be allowed on Linux anyway (though of course other platforms exist too) | 17:38:44 |