Python 3.12.0 from a supply chain security perspective
sethmlarson.dev
Python 3.12.0 from a supply chain security perspective
1–10 of 48 posts
Re: Python 3.12.0 from a supply chain security perspective
#2My biggest takeaway from this article is the Supply chain Levels for Software Artifacts (SLSA) security framework: https://github.com/slsa-framework/slsa-verifier
Re: Python 3.12.0 from a supply chain security perspective
#3Correct me if I'm wrong but SLSA would only prevent artifact tampering (eg. Account takeover on pypi) instead of typo squatting or build script abuse for example?
Re: Python 3.12.0 from a supply chain security perspective
#4As a curiosity, what would it entail to make the two tgz byte-for-byte identical ?
There was/is some discussion in setuptools about how to normalize the tarball (https://github.com/pypa/setuptools/issues/2133#issuecomment-...) coudl something similar be applied to Building Python itself ?
Re: Python 3.12.0 from a supply chain security perspective
#5Is there any effort to integrate SLSA with PyPI? GitHub recently announced[1] that npm support for SLSA is GA now.
[1] https://github.blog/changelog/2023-09-26-npm-provenance-gene...
Re: Python 3.12.0 from a supply chain security perspective
#6In what situation, when it comes to deployed products is any of this relevant?
Having used Python for decades, across multiple organizations starting from mega-corps and down to five programmers I've never used built Python binaries for any project that required Python.
It's not hard to build your own, and it gives you better control of what's included (Python has a handful of optional compile-time dependencies, which most projects don't need).
----
Also, on personal level, I don't think I ever use built binaries from Python.org. I either build them myself, or use whatever the distro maintainers built. Maybe if you develop on Mac / Windows then it matters... but you already chose to suffer by not having control of your tools -- another drop in a bucket, does it even matter?
NB. Also, official Docker images of Python don't use binaries from Python.org. So, nobody who deploys in containers is likely to either build themselves, or to use something other than Python.org binaries.
Re: Python 3.12.0 from a supply chain security perspective
#7In what situation, when it comes to deployed products is any of this relevant? Having used Python for decades, across multiple organizations starting from mega-corps and down to five programmers I've never used built Python binaries for any project that required Python. It's not hard to build your own, and it gives you better control of what's included (Python has a handful of optional compile-time dependencies, whic…
I think it is. There are still millions of devices which either use their own distribution's provided Python package or some form of prepackaged container.
Re: Python 3.12.0 from a supply chain security perspective
#8I have to say it makes sense to me that the binaries would be built from the source tarballs rather than git, seems a bit odd that you'd have separate pipelines and binaries that are produced from a (slightly) different source.
Re: Python 3.12.0 from a supply chain security perspective
#9In what situation, when it comes to deployed products is any of this relevant? Having used Python for decades, across multiple organizations starting from mega-corps and down to five programmers I've never used built Python binaries for any project that required Python. It's not hard to build your own, and it gives you better control of what's included (Python has a handful of optional compile-time dependencies, whic…
As someone that’s done both, you are certainly overstating the suffering endured by not compiling your own Python. I very much believe that this is a consequence of your ideology rather than any indication of frequency.
Re: Python 3.12.0 from a supply chain security perspective
#10In what situation, when it comes to deployed products is any of this relevant? Having used Python for decades, across multiple organizations starting from mega-corps and down to five programmers I've never used built Python binaries for any project that required Python. It's not hard to build your own, and it gives you better control of what's included (Python has a handful of optional compile-time dependencies, whic…
> but you already chose to suffer by not having control of your tools
~Gaslight much?~
Edit:
How about not insulting people who don’t share your point of view?