[dead]
Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
141–150 of 569 posts
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#142Earlier quoted context omitted.
i'm guessing it's accounts they have compromised with the stealer.
They repeat only six sentences during 100+ comments: Worked like a charm, much appreciated. This was the answer I was looking for. Thanks, that helped! Thanks for the tip! Great explanation, thanks for sharing. This was the answer I was looking for.
Over the last ~15 years I have been shocked by the amount of spam on social networks that could have been caught with a Bayesian filter. Or in this case, a fairly simple regex.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#143Earlier quoted context omitted.
And how would that work for single maintainer projects?
They would have to find someone else if they grew too big. Though, the secondary doesn't necessarily have to be a maintainer or even a contributor on the project. It just needs to be someone else to do a sanity check, to make sure it is an actual release. Heck, I would even say that as the project grows in popularity, the amount of people required to approve a release should go up.
So if I'm developing something I want to use and the community finds it useful but I take no contributions and no feature requests I should have to find another person to deal with?
How do I even know who to trust, and what prevents two people from conspiring together with a long con? Sounds great on the surface but I'm not sure you've thought it through.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#144It will only take one agent-led compromise to get some Claude-authored underhanded C into llvm or linux or something and then we will all finally need to reflect on trusting trust at last and forevermore.
You know that people can already write backdoored code, right?
Yeah, and they can write code with vulnerabilities by accident. But this is a new class of problem, where a known trusted contributor can accidentally allow a vulnerability that was added on purpose by the tooling.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#145LiteLLM has like a 1000 dependencies this is expected
https://github.com/BerriAI/litellm/blob/main/requirements.tx...
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#146Earlier quoted context omitted.
They repeat only six sentences during 100+ comments: Worked like a charm, much appreciated. This was the answer I was looking for. Thanks, that helped! Thanks for the tip! Great explanation, thanks for sharing. This was the answer I was looking for.
Over the last ~15 years I have been shocked by the amount of spam on social networks that could have been caught with a Bayesian filter. Or in this case, a fairly simple regex.
Well, large companies/corporations don't care about Spam because they actually benefit from spam in a way as it boosts their engagement ratio
It just doesn't have to be spammed enough that advertisers leave the platform and I think that they sort of succeed in doing so.
Think about it, if Facebook shows you AI slop ragebait or any rage-inducing comment from multiple bots designed to farm attention/for malicious purposes in general, and you fall for it and show engagement to it on which it can show you ads, do you think it has incentive to take a stance against such form of spam
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#147We just can't trust dependencies and dev setups. I wanted to say "anymore" but we never could. Dev containers were never good enough, too clumsy and too little isolation. We need to start working in full sandboxes with defence in depth that have real guardrails and UIs like vm isolation + container primitives and allow lists, egress filters, seccomp, gvisor and more but with much better usability. Its the same requir…
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.
This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties.
Which sounds great, but the way things work now tend to be the exact opposite of that, so there will be no trustable platform to run the untrusted code in. If the sandbox, or the operating system the sandbox runs in, will get breaking changes and force everyone to always be on a recent release (or worse, track main branch) then that will still be a huge supply chain risk in itself.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#148A question from a non-python-security-expert: is committing uv.lock files for specific versions, and only infrequently updating versions a reasonable practice?
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#149Earlier quoted context omitted.
Over the last ~15 years I have been shocked by the amount of spam on social networks that could have been caught with a Bayesian filter. Or in this case, a fairly simple regex.
Well, large companies/corporations don't care about Spam because they actually benefit from spam in a way as it boosts their engagement ratio It just doesn't have to be spammed enough that advertisers leave the platform and I think that they sort of succeed in doing so. Think about it, if Facebook shows you AI slop ragebait or any rage-inducing comment from multiple bots designed to farm attention/for malicious purpo…
Yeah, I almost included that part in my comment, but it still sucks.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#150Does anyone know a good alternate project that works similarly (share multipple LLMs across a set of users)? LiteLLM has been getting worse and trying to get me to upgrade to a paid version. I also had issues with creating tokens for other users etc.
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.