Live data from Hacker News

Telnyx package compromised on PyPI

telnyx.com

141–150 of 153 posts

Re: Telnyx package compromised on PyPI

#141
post #136

Earlier quoted context omitted.

I'll try to reformulate in a simpler way. On debian, all builds happen without internet access. So whatever ends up on the .deb file is either contained on the dependencies or in the orig tarball. Is anything similar done for builds that create artifacts for pypi, so that a certain correspondence between binary file and sources exists? Or is there unrestricted internet access so that what actually ends up on pypi can…

That’s a nice property of centralized package management systems; I don’t think anything exactly like that exists for PyPI. The closest thing would be a cryptographic attestation. (If I wanted to taxonomize these things, I say that the Debian model is effectively a pinky promise that the source artifacts correspond to the built product, except that it’s a better pinky promise because it’s one-to-many instead of many-…

wasnt PEP 740 an attempt to solve this?

Re: Telnyx package compromised on PyPI

#142
post #122

Earlier quoted context omitted.

It delays everything. You can manually override some packages, but the community can't push through it.

RPM (YUM? DNF? RHEL?) lets me subscribe to security updates separately from updates. Does that concept exist in language distribution?

I don't know how it would. Hackers would just claim everything is a security update.

Unless maybe you give special permission to some trusted company to designate certain releases of packages they don't own are security patches... But that sounds untenable.

Re: Telnyx package compromised on PyPI

#143
post #23

For those using uv , you can at least partially protect yourself against such attacks by adding this to your pyproject.toml : [tool.uv] exclude-newer = "7 days" or this to your ~/.config/uv/uv.toml : exclude-newer = "7 days" This will prevent uv picking up any package version released within the last 7 days, hopefully allowing enough time for the community to detect any malware and yank the package version before you…

if everyone waited a week, then everyb would still be installing it it the same time for the first time. This is not a solution.

You don't have to run faster than the bear, you just have to run faster than the other guy.

Re: Telnyx package compromised on PyPI

#144

Earlier quoted context omitted.

That’s a nice property of centralized package management systems; I don’t think anything exactly like that exists for PyPI. The closest thing would be a cryptographic attestation. (If I wanted to taxonomize these things, I say that the Debian model is effectively a pinky promise that the source artifacts correspond to the built product, except that it’s a better pinky promise because it’s one-to-many instead of many-…

wasnt PEP 740 an attempt to solve this?

Depends on what you mean by “this.” If you mean build provenance, yes, if you mean transmuting PyPI into the kind of trust topology that Debian (for example) has, no.

(I think PEP 740 largely succeeds at providing build provenance; having downstream tooling actually do useful things with that provenance is harder for mostly engineering coordination reasons.)

Re: Telnyx package compromised on PyPI

#145
post #122

Earlier quoted context omitted.

RPM (YUM? DNF? RHEL?) lets me subscribe to security updates separately from updates. Does that concept exist in language distribution?

I don't know how it would. Hackers would just claim everything is a security update. Unless maybe you give special permission to some trusted company to designate certain releases of packages they don't own are security patches... But that sounds untenable.

It would have to be handled by the repository owner(e.g. PyPI) similar to how quarantines are done.

Re: Telnyx package compromised on PyPI

#146

Earlier quoted context omitted.

Rather than being hopeful why not start running 'uv' inside sandbox? Why does your python package (cli/Web server/library) need full access to your full disk at the time of execution?

You're doing all of your software development inside containers, all the time? That is very inconvenient.

> That is very inconvenient.

All executions (especially of random third-party code) inside the containers are not inconvenient at all for me.

Infact, I even open-sourced my setup - https://github.com/ashishb/amazing-sandbox

Re: Telnyx package compromised on PyPI

#147
post #117

Earlier quoted context omitted.

You're doing all of your software development inside containers, all the time? That is very inconvenient.

Why? Just open your entire editor/whatever inside a limited namespace and that's it no?

> Why? Just open your entire editor/whatever inside a limited namespace and that's it no?

How will that prevent `npm run dev` or `uv run python` from accessing files outside your current directory?

Re: Telnyx package compromised on PyPI

#148
post #136

Earlier quoted context omitted.

I don’t understand the question, sorry.

I'll try to reformulate in a simpler way. On debian, all builds happen without internet access. So whatever ends up on the .deb file is either contained on the dependencies or in the orig tarball. Is anything similar done for builds that create artifacts for pypi, so that a certain correspondence between binary file and sources exists? Or is there unrestricted internet access so that what actually ends up on pypi can…

[deleted]

Re: Telnyx package compromised on PyPI

#149
post #117

Earlier quoted context omitted.

Why? Just open your entire editor/whatever inside a limited namespace and that's it no?

> Why? Just open your entire editor/whatever inside a limited namespace and that's it no? How will that prevent `npm run dev` or `uv run python` from accessing files outside your current directory?

Do you know what linux namespaces are?

Re: Telnyx package compromised on PyPI

#150
post #17

Earlier quoted context omitted.

Sounds like you're not familiar with https://docs.astral.sh/uv/ ...

It sounds to me like they are: `You know they've given up on backward comparability and version control, when the solution is: run everything in a VM, with its own installation.` uv taking over basically ensures that dependencies won't become managed properly and nothing will work without uv

What do you mean with "basically ensures that dependencies won't become managed properly"?
Post reply on HN