Earlier quoted context omitted.
LiteLLM isn't a good choice for a proxy in any case. It introduces a lot of lag amd latency and the features are often half baked. To me, it looks like a vibecoded application without a product owner. And the code itself isn't very organized either. I evaluated it for a project a few months ago and will never use it for anything production. Theres a few much better alternatives out there.
Could you name some of these better alternatives?
My minute-by-minute response to the LiteLLM malware attack
191–194 of 194 posts
Re: My minute-by-minute response to the LiteLLM malware attack
#192Earlier 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.
I realize this is controversial (and many Python folks would claim anti ethical). But I keep wondering if requiring a small payment for registering and updating packages would help. The money could go to maintaining pypix as well as automated AI analysis. Folks who really couldn't afford it could apply for sponsorship.
Re: My minute-by-minute response to the LiteLLM malware attack
#193Re: My minute-by-minute response to the LiteLLM malware attack
#194Earlier quoted context omitted.
As someone who works in security, it's really neat that you were able to discover this with the help of Claude. That being said the "I just opened Cursor again which triggered the malicious package" message is a bit eye opening. Ideally the instant you suspected malware that machine should have been quarantined and your security personnel contacted.
I get why you say this, but real life is messy and the "fog of war" makes situations far less obvious in the moment. The older I get the more I realize how much we need scrappy, can-do people who don't always follow the "rules". Knowing the "rules" and knowing that people follow the "rules" because "that's what your supposed to do" is itself an avenue for malicious actors to exploit.
Your final sentence is completely irrelevant. Blind rule adherence can be an avenue for exploit in certain scenarios, but this wasn't a case of a developer being tricked into following a bad rule. They didn't follow a real and very well justified standard practice.
The takeaway is "wow, we got lucky, we should have security people to loop in for this next time" not your weird life philosophy about how rule followers are a problem.