Python 3.12.0 from a supply chain security perspective • Hacker News Board

Re: Python 3.12.0 from a supply chain security perspective

#31

Post by miohtama » Thu, Oct 05, 2023, 4:48 PM UTC

syrusakbary wrote: post #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

What’s benefit of this over running Python in a container like Docker?

I know Docker is not 100% watertight, but it’s very unlikely a normal user encounters trojaned Python code that tries to break out from a container.

The run-time penalty for using WebAssembly for Python is pretty severe at the moment, at least what I have tried.

Re: Python 3.12.0 from a supply chain security perspective

#32

Post by andrewaylett » Thu, Oct 05, 2023, 4:55 PM UTC

carreau wrote: post #4

As 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 ?

I suspect you're looking for pristine-tar(1)?

https://manpages.debian.org/stretch/pristine-tar/pristine-ta...

It's intended to solve exactly this problem, but in reverse -- a tarball is extracted to source, and we want to ensure that the sources we've extraced can be traced back to the original tarball.

Re: Python 3.12.0 from a supply chain security perspective

#33

Post by [deleted] » Thu, Oct 05, 2023, 5:01 PM UTC

miohtama wrote: post #31

syrusakbary wrote: post #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

What’s benefit of this over running Python in a container like Docker? I know Docker is not 100% watertight, but it’s very unlikely a normal user encounters trojaned Python code that tries to break out from a container. The run-time penalty for using WebAssembly for Python is pretty severe at the moment, at least what I have tried.

[deleted]

Re: Python 3.12.0 from a supply chain security perspective

#34

Post by kjok » Thu, Oct 05, 2023, 5:07 PM UTC

syrusakbary wrote: post #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

Sandboxing is always good. However, the problem is figuring out accurate per-module policies (what to allow/disallow) For example, a default block-all network policy would also block legitimate functionality.

Re: Python 3.12.0 from a supply chain security perspective

#35

Post by chalsprhebaodu » Thu, Oct 05, 2023, 5:22 PM UTC

miohtama wrote: post #31

syrusakbary wrote: post #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

What’s benefit of this over running Python in a container like Docker? I know Docker is not 100% watertight, but it’s very unlikely a normal user encounters trojaned Python code that tries to break out from a container. The run-time penalty for using WebAssembly for Python is pretty severe at the moment, at least what I have tried.

I’ve personally never been hit by a Trojaned Python project, why use any container or jail at all?

Re: Python 3.12.0 from a supply chain security perspective

#36

Post by carreau » Thu, Oct 05, 2023, 5:25 PM UTC

andrewaylett wrote: post #32

carreau wrote: post #4

As 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 ?

I suspect you're looking for pristine-tar(1)? https://manpages.debian.org/stretch/pristine-tar/pristine-ta... It's intended to solve exactly this problem, but in reverse -- a tarball is extracted to source, and we want to ensure that the sources we've extraced can be traced back to the original tarball.

Hum, that is interesting. I'm more thinking that in a perfect world the pristine-tar delta file should be empty. (Assuming I understand what pristine-tar is doing correctly).

For example I tend to use SOURCE_DATE_EPOCH to be the timestamp of the commit to make sure that anything that embed time is reproducible without extra instruction/manual process specific file.

Re: Python 3.12.0 from a supply chain security perspective

#37

Post by kjok » Thu, Oct 05, 2023, 5:43 PM UTC

chalsprhebaodu wrote: post #35

miohtama wrote: post #31

Earlier quoted context omitted.

What’s benefit of this over running Python in a container like Docker? I know Docker is not 100% watertight, but it’s very unlikely a normal user encounters trojaned Python code that tries to break out from a container. The run-time penalty for using WebAssembly for Python is pretty severe at the moment, at least what I have tried.

I’ve personally never been hit by a Trojaned Python project, why use any container or jail at all?

It is just a matter of time: https://pytorch.org/blog/compromised-nightly-dependency/

Re: Python 3.12.0 from a supply chain security perspective

#38

Post by hoosieree » Thu, Oct 05, 2023, 5:52 PM UTC

syrusakbary wrote: post #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

That's just a matter of perspective. My laptop is already perfectly isolated from your laptop, thank you very much.

Re: Python 3.12.0 from a supply chain security perspective

#39

Post by hifromwork » Thu, Oct 05, 2023, 11:23 PM UTC

syrusakbary wrote: post #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

Hugged to death?

    500: INTERNAL_SERVER_ERROR
    Code: FUNCTION_INVOCATION_FAILED
    ID: arn1::tpcjw-1696548167206-a333e98b1ba8

Re: Python 3.12.0 from a supply chain security perspective

#40

Post by hifromwork » Thu, Oct 05, 2023, 11:26 PM UTC

chalsprhebaodu wrote: post #35

miohtama wrote: post #31

Earlier quoted context omitted.

What’s benefit of this over running Python in a container like Docker? I know Docker is not 100% watertight, but it’s very unlikely a normal user encounters trojaned Python code that tries to break out from a container. The run-time penalty for using WebAssembly for Python is pretty severe at the moment, at least what I have tried.

I’ve personally never been hit by a Trojaned Python project, why use any container or jail at all?

Is this sarcasm? Hard to tell on the internet sometimes. Anyway:

* It's scary enough to be hit one time. It's no fun to have one's all passwords, accounts and keys stolen, and sometimes have files encrypted with a ransom demand on top of that.

* Ideally we'd like to have a secure-by-default world, where the mere act of installing a dependency or running a helper script doesn't compromise your whole system. We're almost there with our phones, we just need to rethink our desktops too.

Of course I don't say you should use containers/sandboxes. It's a tradeoff everyone has to make, but there are many reasons some people (me included) prefer to sandbox everything as much as reasonably possible.