Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.12.0 from a supply chain security perspective

sethmlarson.dev

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Python 3.12.0 from a supply chain security perspective

#41

Post by onesphere »

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?

Shouldn't the OS already do containering with its processes (based on user)?

That's kind of the [functional context] approach I take with: https://github.com/matrixApi/encapsule

Re: Python 3.12.0 from a supply chain security perspective

#42

Post by miohtama »

onesphere wrote: post #41
chalsprhebaodu wrote: post #35

Earlier quoted context omitted.

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

Shouldn't the OS already do containering with its processes (based on user)? That's kind of the [functional context] approach I take with: https://github.com/matrixApi/encapsule

Desktop and server operating system do not prevent any process to access file system. Any process can effectively steal any work you have on your file system, and also perform malware attacks by encrypting your files.

This is not true for mobile operating systems like Android and iOS where processes cannot know about other processes or access file system.

Re: Python 3.12.0 from a supply chain security perspective

#43

Post by insanitybit »

onesphere wrote: post #41
chalsprhebaodu wrote: post #35

Earlier quoted context omitted.

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

Shouldn't the OS already do containering with its processes (based on user)? That's kind of the [functional context] approach I take with: https://github.com/matrixApi/encapsule

The typical User in linux is pretty unconstrained. They can view a lot of global resources, perform arbitrary system calls, view other processes, other users, etc. It's not really a tight sandbox.

That's why Linux offers other, more powerful mechanisms for sandboxing such as namespaces, which are the backbone of containers.

Re: Python 3.12.0 from a supply chain security perspective

#44

Post by crabbone »

evrimoztamur wrote: post #7
crabbone wrote: post #6

In 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.

Why would what was described in the article be of any use to these devices you describe?

If it's built by distribution -- the article is irrelevant. If they use prepackaged container -- the article is irrelevant :|

Re: Python 3.12.0 from a supply chain security perspective

#45

Post by crabbone »

nextlevelwizard wrote: post #13
crabbone wrote: post #6

In 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 have worked with Python for well over a decade and only time I have built my own is to test out the up coming version before it is readily available for my distro. On Windows I just download from python.org and on Mac I get whatever homebrew gets me. Never have I even thought about need to optimise my python executable.

> whatever homebrew gets me

Then you aren't using what's described in the article.

> On Windows

I've already commented on this. This is not a serious deployment. It doesn't matter if it's done with more supervision or less. It's for "recreational" use.

Re: Python 3.12.0 from a supply chain security perspective

#46

Post by crabbone »

jsjohnst wrote: post #10
crabbone wrote: post #6

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

That's not a point of view. This is a consequence of a choice. If you use an operating system that denies you the right to verify its source, then why do you care if an individual component allows you to do that? -- This doesn't make sense. Your system is compromised because you agreed to use a compromised system.

This doesn't say that whoever does this is an idiot. It's about making choices that make sense. If you sign up for a boxing club, but then start complaining about being hit in the face, then you aren't consistent. If you use Windows, and then complain that some component doesn't have a good verification process, then you are just as consistent as the guy who complains about being hit on the face in a boxing club.

Re: Python 3.12.0 from a supply chain security perspective

#47

Post by crabbone »

tmpX7dMeXU wrote: post #9
crabbone wrote: post #6

In 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.

Suffering doesn't come from not compiling. Suffering comes from inability to trust your system. Not everyone suffers from this. Most don't care. But then the question is why would they care in the case described by the article, if they don't give a rats ass in general?

Re: Python 3.12.0 from a supply chain security perspective

#48

Post by jsjohnst »

crabbone wrote: post #46
jsjohnst wrote: post #10

Earlier quoted context omitted.

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

That's not a point of view. This is a consequence of a choice. If you use an operating system that denies you the right to verify its source, then why do you care if an individual component allows you to do that? -- This doesn't make sense. Your system is compromised because you agreed to use a compromised system. This doesn't say that whoever does this is an idiot. It's about making choices that make sense. If you s…

Thanks for confirming your true colors. Have a nice life!
Post reply on HN