| 24 Jul 2025 |
 emily | since it changes hashes | 19:46:04 |
| emily | what is SHA-1 even used for at this point? seems like it'd be better to try phasing it out? I assume nothing in Nixpkgs is pinned by SHA-1 | 19:46:20 |
| emily | well, actually, for Git they just run it in checking mode and abort if a potentially-colliding input is detected | 19:46:47 |
| emily | which is still a compat break, but at least not silent hash changing | 19:46:52 |
| emily | if it's for Git revs then you want to be doing that but I assume libgit2/git(1) will already handle the hashing there | 19:47:08 |
| emily | pkgs/servers/mx-puppet-discord/node-packages.nix
111: sha1 = "532e01241dbcb0f2769f1b9a7cde313d30101173";
120: sha1 = "68018cab4f59834b3fef2e59fbfd52938403e001";
129: sha1 = "52b0e8bb808a1202602899af67939b049dd42402";
138: sha1 = "0a37a3f9430ff7c29512d29882e25ae738a31283";
🫣
| 19:49:51 |
| emily | apparently these are the only SHA-1 pins left in Nixpkgs | 19:49:55 |
| emily | seems like giving them the URL literals etc. treatment would be the way forward | 19:51:48 |
 jade_ | agreed | 22:10:28 |
| jade_ | i think the correct attitude is just making lix reject those | 22:10:36 |
| jade_ | also surely mx-puppet-discord is unmaintained lol | 22:10:59 |
| jade_ | * also surely mx-puppet-discord is unmaintained cuz that looks like generated code lol | 22:11:09 |
| emily | it's some huge generated Node package blob yeah. no idea about maintenance state | 22:12:58 |
| emily | In reply to @jade_:matrix.org
i think the correct attitude is just making lix reject those probably want to keep around a flag forever for old Nixpkgs compat. though I don't know how high a priority that is since I think Lix has removed things used by prehistoric Nixpkgs. but SHA-1 was probably more recently used | 22:14:19 |
| emily | e.g. by everyone's favourite Chromium update script | 22:14:32 |
| jade_ | indeed. i mean. the real point is that lix becomes a linter when it bans stuff | 22:14:38 |
| emily | which is an argument against using SHA1DC | 22:14:46 |
| jade_ | * indeed. i mean. the real point is that lix becomes a linter when it bans stuff and ensures it is gone from nixpkgs forever | 22:14:49 |
| jade_ | oh right because the horrible chromim thing actually abuses a collision right? | 22:15:01 |
| emily | since the Chromium update script specifically relied on SHA-1 collisions | 22:15:03 |
| jade_ | thats still totally absurd to me that nixpkgs did that | 22:15:26 |
| emily | I'm pretty sure it was done for the meme. | 22:15:40 |
| emily | there was no technical constraint pointing to using Nix for it I think | 22:15:53 |
| emily | fwiw SHA1DC is also substantially slower than the best SHA-1 implementations, especially hardware-accelersted ones. it could be more competitive but nobody cares enough because it only matters for Git and OpenPGP. irrelevant for Nix anyway | 22:17:12 |
| jade_ | answer: not. it was a casualty of one of the not banning nazis incidents https://github.com/NixOS/nixpkgs/pull/428183 | 23:48:00 |
| 25 Jul 2025 |
| emily | btw, to be clear the Chromium update script hack was removed long ago | 00:53:12 |
| emily | so it's only relevant for historical compatibility; I think disabling SHA-1 by default with a flag to allow it is unlikely to break anyone's workflow | 00:53:30 |
|  Federico Damián Schonborn (he/they) changed their display name from Wormy McWormface 🏳️🌈 (he/they) to Cat McFishface 🏳️🌈 (he/they). | 01:43:06 |
|  Simon Hauser joined the room. | 07:04:33 |
| 26 Jul 2025 |
 raitobezarius | In reply to @emilazy:matrix.org
fwiw SHA1DC is also substantially slower than the best SHA-1 implementations, especially hardware-accelersted ones. it could be more competitive but nobody cares enough because it only matters for Git and OpenPGP. irrelevant for Nix anyway i feel like this is anyway a non-question for Lix, we are using the git CLI, if git starts using sha1dc for checking reasons, it will probably exit during one of the relevant fetching operations and we are automatically protected | 00:43:15 |
