5 ms·
As a user of PyPI, what’s a best practice to protect against compromised libraries? I fear that freezing the version number is inadequate because attackers (wh
by clbrmbr 2y ago
As a user of PyPI, what’s a best practice to protect against compromised libraries?
I fear that freezing the version number is inadequate because attackers (who don’t forget, control the dependency) could change the git tag and redeploy a commonly used version with different code.
Is it really viable to use hashes to lock the requirements.txt?
- pabs3 2y agoDownload the libraries' real source repos, apply static analysis tools, audit the source code manually, then build wheels from source instead of using prebuilt stuff from PyPI. Repeat for every update of every library. Publish your audits using crev, so others can benefit from them. Push the Python community to think about Reproducible Builds and Bootstrappable Builds. https://github.com/crev-dev/ https://github.com/crev-dev/ https://reproducible-builds.org/ https://reproducible-builds.org/ https://bootstrappable.org/ https://bootstrappable.org/
- thangngoc89 2y agoThis is where tools like poetry, uv with lock files shine. The lock files contains all transient dependencies (like pip freeze) but they do it automatically.
- woodruffw 2y agoRelease files on PyPI are immutable: an attacker can’t overwrite a pre-existing file for a version. So if you pin to an exact version, you are (in principle) protected from downloading a new malicious one. The main caveat to the above is that files are immutable on PyPI, but releases are not. So an attacker can’t overwrite an existing file (or delete and replace one), but they can always add a more specific distribution to a release if one doesn’t already exist. In practice, this means that a release that doesn’t have an arm64 wheel (for example) could have one uploaded to it. TL;DR: pinning to a version is suitable for most settings; pinning to the exact set of hashes for that version’s file will prevent new files from being added to that version without you knowing.
- TZubiri 2y agoThe best practice is to reduce your dependencies. Trim your requirements.txt
- HeatrayEnjoyer 2y agoYour software should execute as little code written outside your offices as possible.
- TZubiri 2y agoEspecially those without a commercial contract. I'm fine paying for an api but what is unprofessional is installing random stuff from github.com/GuyProgrammer/Project78 with an anime girl as a profile pic.
- luismedel 2y agoIt surprises me how much companies rely on that kind of projects without 1) making a proper assessment and 2) cloning the project to ensure it isn't tampered in the future.
- TZubiri 2y agoNot only do they not clone projects or freeze their dependencies, but they are pressured to constantly update to the latest version to avoid vulnerabilities ( while introducing risk of new ones)
- onei 2y agoThat seems like short-sighted advice. My company probably isn't paying me to write crypto, web frameworks, database drivers, etc. If it's not where I'm adding business value, I would generally try to use a third-party solution, assuming there's no stdlib equivalent. That likely means my code is an overwhelming minority of what gets executed. If C dominates your codebase or you're squeezing out every inch of performance, then sure, you may well have written everything libc is missing. In Python, or another language that had a thriving ecosystem of third-party packages, it seems wasteful to write it all in-house.
- d0mine 2y agoAre you sure pypi allows to modify old published package? Lock files may contain hashes.