Compromised PyTorch-nightly dependency chain December 30th, 2022

Re:Compromised PyTorch-nightly dependency chain December 30t... by Beltalowda on Saturday December 31, 2022 @10:17PM (#34203232)

Not sure if you need anything as complex as that: just the Python tools recording the hash of the dependency and storing that in the git repo should be enough to prevent this particular problem. e.g. go.sum contains a hash of the entire source. I believe npm and cargo are similar. This way the user should always get the exact same dependency that I added as a developer, no matter what happens with their settings or connection or whatnot.

Not familiar with Python's ecosystem at all, but judging from this commit[1] it doesn't seem to have anything it(?)

[1]: https://github.com/pytorch/pytorch/commit/bc92444b34dfbe3841...

[ Parent | on HN ]

Re:Compromised PyTorch-nightly dependency chain December 30t... by jakear on Saturday December 31, 2022 @10:19PM (#34203242)

That protects this one avenue, but the more common one I've seen (npm land) is a compromised downstream dependency that gets automatically upgraded for whatever reason.

Regardless - I want to be protected even when the Author of the package themselves is compromised (either by their tokens being stolen or them manually compromising the project)

[ Parent | on HN ]

Re:Compromised PyTorch-nightly dependency chain December 30t... by alexiaa on Sunday January 01, 2023 @07:35AM (#34205819)

it does, but to use hashes you'd have to pin exact versions of every dependency, which is generally undesirable for a library

[ Parent | on HN ]