| 19 Dec 2024 |
6pak | actually nuget uses contentHash, which ignores the signature | 12:01:29 |
6pak | which is why, at least in my case the hash was the same for both sources in packages.lock.json | 12:01:53 |
6pak | but different in fetchNupkg | 12:01:57 |
6pak | * but different in fetchNuGet | 12:02:03 |
6pak | from the first glance, that's not what the code does | 12:03:55 |
6pak | but turns out I don't have a test case to check | 12:04:11 |
6pak | can we do the same in nix somehow? otherwise we wont be able to reuse any kind of hashes from nuget metadata | 12:10:30 |
GGG | might be possible if we undo the signature in the fetchurl postPatch step | 12:12:28 |
GGG | only if the hashes match though | 12:12:38 |
6pak |  Download image.png | 12:20:18 |
6pak | ;p | 12:20:22 |
GGG | owell, guess they lied then | 12:20:55 |
GGG | smh my head | 12:21:03 |
6pak | the same can happen randomly without switching the source order if the first one is slow enough | 12:21:03 |
6pak | * the same can happen randomly without switching the source order if the first request is slow enough | 12:21:10 |
6pak | this is so cursed | 12:21:47 |
6pak | PackageReference should have a required Source property, change my mind | 12:23:00 |
GGG | I don't think it should matter honestly, unless if we're dealing with adversary sources or something | 12:23:53 |
6pak | nuget.org is an adversary source | 12:24:27 |
6pak | anyone can upload there | 12:24:31 |
6pak | and if you rely on a internal package thats not on nuget.org | 12:24:40 |
6pak | anyone can claim the package id there | 12:24:46 |
6pak | and you will just restore that instead if you dont have package source mappings setup | 12:25:03 |
GGG | fair | 12:25:12 |
6pak | custom sources without mapping is a big security risk | 12:25:17 |
6pak | and shouldn't be allowed imo | 12:25:20 |
6pak | like at all | 12:25:27 |
GGG | I guess that's the point of having nuget lockfiles | 12:25:36 |
GGG | if they didn't suck so much | 12:25:39 |
GGG | * if only they didn't suck so much | 12:25:46 |