# add any dependency file patterns
osv-scanner -r .
as your projects mature, add osv-scanner as a blocking step to fail your installs before the code gets installed / executed.Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
371–380 of 569 posts
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#372my takeaway from this is that it should now be MANDATORY to have an LLM do a scan on the entire codebase prior to release or artifact creation. do NOT use third party plugins for this. it's so easy to create your own github action to digest the whole codebase and inspect third party code. it costs tokens yes but it's also cached and should be negligible spend for the security it brings.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#373Earlier quoted context omitted.
This must be super stressful for you, but I do want to note your "I'm sorry for this." It's really human. It is so much better than, you know... "We regret any inconvenience and remain committed to recognising the importance of maintaining trust with our valued community and following the duration of the ongoing transient issue we will continue to drive alignment on a comprehensive remediation framework going forward…
Lawyers are slowly eating humanity.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#374Also the repo is so active that it's very hard to understand the state of issues and PRs, and the 'day 0' support for GPT-5.4-nano took over a week! Still, tough situation for the maintainers who got hacked.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#375Earlier quoted context omitted.
This is the security shortcuts of the past 50 years coming back to bite us. Software has historically been a world where we all just trust each other. I think that’s coming to an end very soon. We need sandboxing for sure, but it’s much bigger than that. Entire security models need to be rethought.
What we need is accountability and ties to real-world identity. If you're compromised, you're burned forever in the ledger. It's the only way a trust model can work. The threat of being forever tainted is enough to make people more cautious, and attackers will have no way to pull off attacks unless they steal identities of powerful nodes. Like, it shouldn't be a thing that some large open-source project has some 4th…
Who's gonna enforce that?
> If you're compromised, you're burned forever in the ledger.
Guess we can't use XZ utils anymore cause Lasse Collin got pwned.
Also can't use Chalk, debug, ansi-styles, strip-ansi, supports-color, color-convert and others due to Josh Junon also ending up a victim.
Same with ua-parser-js and Faisal Salman.
Same with event-stream and Dominic Tarr.
Same with the 2018 ESLint hack.
Same with everyone affected by Shai-Hulud.
Hell, at that point some might go out of their way to get people they don't like burned.
At the same time, I think that stopping reliance on package managers that move fast and break things and instead making OS maintainers review every package and include them in distros would make more sense. Of course, that might also be absolutely insane (that's how you get an ecosystem that's from 2 months to 2 years behind the upstream packages) and take 10x more work, but with all of these compromises, I'd probably take that and old packages with security patches, instead of pulling random shit with npm or pip or whatever.
Though having some sort of a ledger of bad actors (instead of people who just fuck up) might also be nice, if a bit impossible to create - because in the current day world that's potentially every person that you don't know and can't validate is actually sending you patches (instead of someone impersonating them), or anyone with motivations that aren't clear to you, especially in the case of various "helpful" Jia Tans.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#376Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#377LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…
Similar to delve, this guy has almost no work experience. You have to wonder if YC and the cult of extremely young founders is causing instability issues in society at large?
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#378https://github.com/crewAIInc/crewAI/commit/8d1edd5d65c462c3d...
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#379Earlier quoted context omitted.
Bifrost is the only real alternative I'm aware of https://github.com/maximhq/bifrost
Virtual Keys is an Enterprise feature. I am not going to pay for something like this in order to provide my family access to all my models. I can do without cost control (although it would be nice) but I need for users to be able to generate a key and us this key to access all the models I provide.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#380CrewAI (uses litellm) pinned it to 1.82.6 (last good version) 5 hours ago but the commit message does not say anything about a potential compromise. This seems weird. Is it a coincidence? Shouldn’t users be warned about a potential compromise? https://github.com/crewAIInc/crewAI/commit/8d1edd5d65c462c3d...