Earlier quoted context omitted.
[flagged]
100% with you. Anything that builds from the first try is 100% malicious. No real software builds without 5-30 tweaks of the makefile. And anything on npm/pip is malicious with a fixed chance that you have no control over, as seen in this attack. But the data remains: no supply chain attacks on libc yet, so even if it COULD happen, this HAS and that merely COULD.
My minute-by-minute response to the LiteLLM malware attack
111–120 of 194 posts
Re: My minute-by-minute response to the LiteLLM malware attack
#112Earlier quoted context omitted.
Sure, but this is a pretty onerous restriction. Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)
They will certainly get worse. LLMs make it so much easier.
Re: My minute-by-minute response to the LiteLLM malware attack
#113Re: My minute-by-minute response to the LiteLLM malware attack
#114We mitigate this attack with the very uninspiring "wait 24h before dep upgrades" solution which is luckily already supported in uv.
Re: My minute-by-minute response to the LiteLLM malware attack
#115Earlier quoted context omitted.
The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages. PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
It should not let people download unscanned dependencies without a warning and asking the user to override and use a potentially insecure package. If such security bug is critical enough to need to bypass this time (spoiler: realistically it is not actually that bad for a security fix to be delayed) they can work with the pypi security team to do a quicker manual review of the change.
Re: My minute-by-minute response to the LiteLLM malware attack
#116I am confused; did you ever actually email anyone about the vuln? The AI suggests emailing security emails multiple times, but as I'm reading the timeline, none of the points seem to suggest this was ever done, only that a blog post was made, shared on Reddit, and then indirectly , the relevant parties took action. I'm hoping this just isn't on the timeline.
> I'm the engineer who got PyPI to quarantine litellm.
In guessing they used a tool other than Claude Code to serve the email.
Re: My minute-by-minute response to the LiteLLM malware attack
#117[flagged]
But then what happens when everyone just shifts their window too. This solution is a misuse of the commons type thing where you just take advantage of letting others get poisoned and see if they drop
Re: My minute-by-minute response to the LiteLLM malware attack
#118Earlier quoted context omitted.
The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages. PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
It should not let people download unscanned dependencies without a warning and asking the user to override and use a potentially insecure package. If such security bug is critical enough to need to bypass this time (spoiler: realistically it is not actually that bad for a security fix to be delayed) they can work with the pypi security team to do a quicker manual review of the change.
I don't think PyPI should be in the business of saying if a piece of software is safe to install or not.
Re: My minute-by-minute response to the LiteLLM malware attack
#119Earlier quoted context omitted.
It should not let people download unscanned dependencies without a warning and asking the user to override and use a potentially insecure package. If such security bug is critical enough to need to bypass this time (spoiler: realistically it is not actually that bad for a security fix to be delayed) they can work with the pypi security team to do a quicker manual review of the change.
sadly I still worry about that. An install fails once, you you hard code the --force flag in all your CI/CD jobs and we are back in the same place again. I am not sure what the answer is, though problems...
Re: My minute-by-minute response to the LiteLLM malware attack
#120I am confused; did you ever actually email anyone about the vuln? The AI suggests emailing security emails multiple times, but as I'm reading the timeline, none of the points seem to suggest this was ever done, only that a blog post was made, shared on Reddit, and then indirectly , the relevant parties took action. I'm hoping this just isn't on the timeline.
The first line of the post is: > I'm the engineer who got PyPI to quarantine litellm. In guessing they used a tool other than Claude Code to serve the email.