Live data from Hacker News

Python 3.12.0 from a supply chain security perspective

sethmlarson.dev

21–30 of 48 posts

Re: Python 3.12.0 from a supply chain security perspective

#21
This is great. On a related note, we recently compiled Python 3.12.0 to WebAssembly: using it should shield almost any use case of malicious behavior even on external untrusted modules.

https://wasmer.io/python/python

Run it locally and see that filesystem access and network are completely sandboxed by default! :)

  wasmer run python/python

Re: Python 3.12.0 from a supply chain security perspective

#24

This sounds great if you want the PSF to make these changes I think the next step would be a PEP that describes it.

This doesn't change the Python language or packaging so wouldn't require a PEP, I'm working with release managers on this GitHub repo: https://github.com/python/release-tools

Re: Python 3.12.0 from a supply chain security perspective

#26
post #25
post #23

Didn't Anaconda show that the whole Pip approach is flawed and we need a language-agnostic/multi-language approach?

npm works great on JavaScript.

Are you being serious?

https://www.cpomagazine.com/cyber-security/open-source-devel...

https://therecord.media/malware-found-in-npm-package-with-mi...

...

and the list goes on

Re: Python 3.12.0 from a supply chain security perspective

#27

This is great. On a related note, we recently compiled Python 3.12.0 to WebAssembly: using it should shield almost any use case of malicious behavior even on external untrusted modules. https://wasmer.io/python/python Run it locally and see that filesystem access and network are completely sandboxed by default! :) wasmer run python/python

> recently compiled Python 3.12.0 to WebAssembly

Any chain is as strong as its weakest link.

Re: Python 3.12.0 from a supply chain security perspective

#28
post #27

This is great. On a related note, we recently compiled Python 3.12.0 to WebAssembly: using it should shield almost any use case of malicious behavior even on external untrusted modules. https://wasmer.io/python/python Run it locally and see that filesystem access and network are completely sandboxed by default! :) wasmer run python/python

> recently compiled Python 3.12.0 to WebAssembly Any chain is as strong as its weakest link.

But not all composition is a chain.

A sandboxed solution is at least as strong as the sandbox.

Re: Python 3.12.0 from a supply chain security perspective

#29

My biggest takeaway from this article is the Supply chain Levels for Software Artifacts (SLSA) security framework: https://github.com/slsa-framework/slsa-verifier

> biggest takeaway from this article is the Supply chain Levels for Software Artifacts (SLSA) security framework

See also GUAC from Kusari, Google, Citi, and others:

“GUAC (Graph for Understanding Artifact Composition) aims to fill in the gaps by ingesting software metadata, like SBOMs, and mapping out relationships between software. When you know how one piece of software affects another, you’ll be able to fully understand your software security position and act as needed.”

https://guac.sh

https://www.kusari.dev

Re: Python 3.12.0 from a supply chain security perspective

#30
post #25
post #23

Didn't Anaconda show that the whole Pip approach is flawed and we need a language-agnostic/multi-language approach?

npm works great on JavaScript.

You can even use npm to manage and publish Python code, or could a few years ago if they haven't added constraints on the registry since then
Post reply on HN