I'm working on a multi signature system for file authentication that can detect unauthorized file publications. It is self-funded, open source, auditable, self hostable, accountless. I'm looking for testers and feedback, don't hesitate to contact me if interested.
More info at https://asfaload.com/
Telnyx package compromised on PyPI
121–130 of 153 posts
Re: Telnyx package compromised on PyPI
#122Earlier quoted context omitted.
Does this also delay delivery of security fixes? Is there an override mechanism for a log4j type event?
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?
Re: Telnyx package compromised on PyPI
#123So 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?
Don't have the token on your hands. Use OICD ideally, or make sure to setup carefully as a repository secret. Ensure the workflow runs in a well permission read, minimal dependency environment. The issue with OICD is that it does not work with nested workflows because github does not propagate the claims.
*OIDC
Re: Telnyx package compromised on PyPI
#124At this point, I'm not updating anything using Python. Not that I had the option anyway, because everything using Python breaks if you update it. 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. Apparently it's also needed for security, but the VMs aren't really set up to be secure. I don't get why everything math heavy u…
[flagged]
Re: Telnyx package compromised on PyPI
#125> 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?
No. I was one of the "lucky" ones forced to use 2FA from the beginning. I also wrote the twine manpage (in debian) because at the time there was even no way of knowing how to publish at all. Basically you enable 2FA on your account, go on the website, generate a token, store it in a .txt file and use that for the rest of your life without having to use 2FA ever again. I had originally thought you'd need your 2FA ever…
A stolen PyPI token was uses for the compromized litellm package. I wouldn't be surprized if tokens will be decommissioned in the aftermath of these recent hijackings. That wouldn't prevent these attacks as you mentioned SSH keys were stolen (and a Github token in the case of litellm). It would be a way for PyPA to brush off liability without securing anything.
Re: Telnyx package compromised on PyPI
#126Earlier quoted context omitted.
I believe they are saying that by the time you need something like uv, your project already has too many dependencies. Its the unnecessarily large supply chain that's the problem, and uv exists to solve a problem that you should try to avoid in the first place. I think uv is great, but I somewhat agree. We see this issue with node/npm. We need smaller supply chains/less dependencies overall, not just bandaiding over…
This line of thought is honestly a bit silly - uv is just a package manager that actually does its job for resolving dependencies. You’re talking about a completely orthogonal problem.
uv is really only something you need if you already aren't managing dependencies responsibly, imo.
Re: Telnyx package compromised on PyPI
#127At this point, I'm not updating anything using Python. Not that I had the option anyway, because everything using Python breaks if you update it. 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. Apparently it's also needed for security, but the VMs aren't really set up to be secure. I don't get why everything math heavy u…
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
Re: Telnyx package compromised on PyPI
#128For 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.
Let security researchers, staff and automated malware scanners take a bite first.
Re: Telnyx package compromised on PyPI
#129Earlier quoted context omitted.
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 environm…
If they have compromised the token wouldn't that mean the developer is compromised and such access can be used to just put "curl whatever" into the build and publish that payload on pypi?
I don’t understand the question, sorry.
Re: Telnyx package compromised on PyPI
#130> 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?
No. I was one of the "lucky" ones forced to use 2FA from the beginning. I also wrote the twine manpage (in debian) because at the time there was even no way of knowing how to publish at all. Basically you enable 2FA on your account, go on the website, generate a token, store it in a .txt file and use that for the rest of your life without having to use 2FA ever again. I had originally thought you'd need your 2FA ever…
I’ll bypass the technical inaccuracies in this comment to focus on the main important thing.
> Then they have the trusted publisher thing (which doesn't and won't work with codeberg) where they just upload whatever comes from github's runners.
There’s no particular reason it wouldn’t work; it’s just OIDC and Codeberg could easily stand up an IdP. If you’re willing to put the effort into making this happen, I’d be happy (as I’ve said before) to review any contributions towards this end.
(The only thing that won’t work here is imputing malicious intent; that makes it seem like you have a score to settle rather than a genuine technical interest in the community.)