| 14 Oct 2025 |
 emily | so Nixpkgs would need
- parsing and serialization for SRI and
<algo>:<digest> that matches the implementation
- a lookup table between hashes and byte sizes
and the code would be Lix-specific (because Nix has chosen that strings cannot contain NUL bytes so the intermediate values would not be valid)
that may be fine
| 16:26:06 |
 raitobezarius | I'd say that the code is specific to those who have !(builtins?convertHash) true but idk | 16:26:48 |
| emily | if you're going to allow NUL bytes in strings you surely want to be able to handle Base64 etc. in general | 16:26:52 |
| raitobezarius | I mean you're right | 16:26:53 |
| raitobezarius | Perhaps, we should advertise NUL in our bytes lol | 16:27:01 |
| emily | Nix32 on the other hand is cursed | 16:27:02 |
 K900 | That's a much later problem tbh | 16:27:02 |
| raitobezarius | builtins.features.canContainNULInStrings | 16:27:06 |
| K900 | And definitely not a convertHash sized problem | 16:27:09 |
| emily | AIUI NUL bytes have already been decided to be allowed. | 16:27:22 |
| K900 | Like I think having something of this shape is good long term | 16:27:23 |
| raitobezarius | NUL bytes were merged, yeah | 16:27:33 |
| K900 | But convertHash isn't even the right shape | 16:27:36 |
| raitobezarius | Lix HEAD can have binary data now in strings | 16:27:40 |
| K900 | Yes but it's not a problem for convertHash shaped things | 16:27:46 |
| raitobezarius | (And we eliminated the security issue via a lint) | 16:27:50 |
| emily | it seems totally reasonable to want to be able to convert between lock file formats that use SRI vs. base16 in Nix | 16:28:01 |
| K900 | Yes but also ehhhhhhhhhhhhhhhhhhh | 16:28:21 |
| raitobezarius | emily: Are you satisfied with the Lix proposal? I'm going to context switch to another thing | 16:28:25 |
| K900 | Like the endpoint will probably be an FOD | 16:28:28 |
| K900 | And FODs accept both | 16:28:34 |
| raitobezarius | Do you know when would you like this to happen? | 16:28:35 |
| K900 | And should continue to accept both IMO | 16:28:39 |
| emily | well, we are here because convertHash is not desired and I said the main way I can imagine decomposing it is to split out SRI/<hash>:<algo> parsing, and to split conversion/deconversion using NUL bytes in strings | 16:28:38 |
| K900 | Like all the uses of convertHash I'm seeing right now are "convert to SRI and shove it in a FOD" | 16:29:17 |
| * raitobezarius is not going to debate the need of convertHash or not for end user code | 16:28:59 |
| emily | I'm ambivalent. I'm not really trying to push for it. I'm just noting that it's something that comes up fairly often and that we've had Nixpkgs hash divergence from attempts at feature detecting it | 16:29:18 |
| emily | the demand is not from me, but there is demand :) | 16:29:23 |
| K900 | Which is objectively useless | 16:29:37 |
| K900 | And could just be "sha256:" + hash | 16:29:43 |
