| 14 Oct 2025 |
 emily | I am also not entirely sure if there are any gremlins in the <algo>:<digest> format etc. which would be a pain to deal with in Nix | 16:06:15 |
| emily | though it's probably tolerable if it's just in one lib function in Nixpkgs | 16:06:22 |
 raitobezarius | Do you have a clear example of case where {from,to}NixBase32 would not roundtrip? | 16:06:32 |
| raitobezarius | It's already known that Nix flavor of base32 is a bit special, but I cannot remember of seeing there was unambiguous cases. If anything, Nix always accepted $BASE32 + any char for a while (and probably still do). | 16:07:06 |
| emily | frankly the hash formats are all very weird and I am not sure if it is really better to have their format details exposed to userspace rather than just treating them as opaque but interconvertible blogs | 16:07:17 |
| raitobezarius | It never honored any form of strict implementation of RFC4648 | 16:07:22 |
| emily | e.g. proliferation of Base32 use doesn't seem like a great thing | 16:07:32 |
| emily | I believe there are cases where appending (or prepending?) a NUL byte will not change the result | 16:07:40 |
| emily | because of padding | 16:07:45 |
| emily | and therefore decoding must fail to round-trip on one of them | 16:07:56 |
| emily | I recall running into this when factoring out the Base32 functions | 16:08:03 |
| emily | Base32 lacks anything like Base64's = | 16:08:46 |
| raitobezarius | There are, but it only cause problem for strict implementations outside of CppNix/Lix | 16:09:48 |
| raitobezarius | (i.e. back when we dealt with nixbase32 in snix.) | 16:10:02 |
| emily | well, I mean that with to/from functions, Nixpkgs lib will have to implement the <algo>:<digest> and SRI logic 1:1 to match the implementations | 16:10:28 |
| raitobezarius | I'm really unhappy about convertHash as a primitive, it also does not enable any form of detection of what pairs does it support and what it can do | 16:10:34 |
| emily | this may be more "pure" but it also feels a bit error-prone compared to just having convertHash handle it | 16:10:43 |
| emily | but it at least only needs solving once | 16:10:52 |
| emily | (unless the quirks change later) | 16:10:55 |
| raitobezarius | Yeah, but that direction is easy because the implementations accepts more than they should | 16:10:57 |
| raitobezarius | which would be a regression caught by tests hopefully | 16:11:30 |
| emily | I think you would need a size parameter | 16:11:35 |
| emily | which is not very nice | 16:11:39 |
| emily | because now Nixpkgs has a look-up table of hashes to byte sizes too… etc. | 16:11:49 |
| emily | not the end of the world | 16:12:02 |
| raitobezarius | I'm pretty confident that we don't want convertHash in Lix, we might accept convertBinary but I'm not super comfy about getting this on a short timeline, I'm confident about {from,to}{NixBase32,Base16,Base64} primitives in builtins.conversions and we can look at an convertHash implementation beforehand with such built-ins on a short timeline | 16:13:05 |
| raitobezarius | I don't know what is the timeline you are operating with to have this code available | 16:13:39 |
| raitobezarius | Seems like the passAsFile thing used there is exploiting an implementation detail about passAsFile internal details, which does not seem to be an excellent usecase for convertHash | 16:14:51 |
 K900 | OK question (please tell me if I'm being stupid), what's the actual use case for this? | 16:16:27 |
| emily | I don't care about it on a personal level, I just know that it regularly comes up as a blocker for using Lix for people, e.g. brew-nix used it, https://github.com/search?q=convertHash+language%3Anix&type=code shows many examples, and as i linked in https://github.com/NixOS/nixpkgs/pull/451929 an attempt to do feature-detection in Nixpkgs caused hash divergence between Nix and Lix | 16:16:35 |
