[deleted]
Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
481–490 of 569 posts
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#482[dead]
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#483Earlier quoted context omitted.
Pinning doesn’t help you. They can replace the package and you’ll get the new one. You have to vendor the dependencies.
I don't think pypi or npm allow replacing existing packages?
They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#484Earlier quoted context omitted.
alot of software isnt that important so its fine, but some actually is important. especially with a branding name slapped on it that people will trust
The industry needs to step up and plant a flag for professionalization certifications for proper software engineering. Real hard exams etc
I can't even imagine what these exams would look like. The entire profession seems to boil down to making the appropriate tradeoffs for your specific application in your specific domain using your specific tech stack. There's almost nothing that you always should or shouldn't do.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#485So now we feel the need to add malware protection into the CI, like we put comodo on windows 7 and pray while surfing shady torrent websites ?
It is pretty ironic that an extra tool used to protect against threats gets compromised and creates an even bigger threat.
Some here talks about better isolation during development, CI, but the surface area is huge, and probably impractical. Even if the CI is well isolated, the produced package is compromised.
What about reducing the number of dependencies ? Integrating core functionalities in builtin language libraries ? Avoiding frequent package updates ? Avoiding immature/experimental packages from developers of unknown reliability ?
Those issues are grave. I see no future when those get rarer, and I am afraid they may wipe the open-source movement credibility.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#486> the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow.
What is the source of compromise?
Does anyone have a list of other compromised projects?
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#487Earlier quoted context omitted.
The server can also put malware in the .tar.gz. Are you really checking all the files in there, even the binaries? If you don't what's the point of checking only the install script?
> If you don't what's the point of checking only the install script? The .tar.gz can be checksummed and saved (to be sure later on that you install the same .tar.gz and to be sure it's still got the same checksum). Piping to Bash in one go not so much. Once you intercept the .tar.gz, you can both reproduce the exploit if there's any (it's too late for the exploit to hide: you've got the .tar.gz and you may have saved…
> And I do religiously verify that the "file inside the script" does have a valid signature when it has one.
If you want to go down this route, there is no need to reinvent the wheel. You can add custom repositories to apt/..., you only need to do this once and verify the repo key, and then you get this automatic verification and installation infrastructure. Of course, not every project has one.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#488Earlier quoted context omitted.
The server can also put malware in the .tar.gz. Are you really checking all the files in there, even the binaries? If you don't what's the point of checking only the install script?
> Are you really checking all the files in there, even the binaries? One should never trust the binaries, always build them from source, all the way down to the bootloader. https://bootstrappable.org/ Checking all the files is really the only way to deal with potential malware, or even security vulns. https://github.com/crev-dev/
Nice ideal, but Chrome/Firefox would take days to build on your average laptop (if it doesn't run out of memory first).
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#489Earlier quoted context omitted.
I don't think pypi or npm allow replacing existing packages?
They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.
It actually wasn't. That was one of the reasons why I looked into what was changed. Even 1.82.6 is only at an RC release on github since just before the incident.
So the fact that 1.82.7 and then 1.82.8 were released within an hour of each other was highly suspicious.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#490Earlier quoted context omitted.
That's true, but it seems far more complex than just moving trivy to a separate workerflow with no permissions and likely physical isolation between it and a credential. I'm pretty wary of the idea that malware couldn't just privesc - it's pretty trivial to obtain root on a user's laptop. Running as a separate, unprivileged user helps a ton, but again, I'm skeptical of this vs just using a github workflow.
I'm looking for more general solutions. "Properly configure Trivy" is too specific, it's obvious in hindsight but not before. Privilege escalation on macOS is very hard indeed. Apple have been improving security for a long time, it is far, far ahead of Linux or Windows in this regard. The default experience in Xcode is that a release-mode app you make will be sandboxed, undebuggable, have protected keychain entries o…
Privesc is trivial on every desktop OS if you run as a regular user. I can write to your rc files so it's game over.
App Store apps are the exception, which is great, but presumably we're not talking about that? If we are, then yeah, app stores solve these problems by making things actually sandboxed.