| ▲ | petesergeant 3 hours ago |
| > There currently exists a private LiteLLM registry for enterprise customers, in which we are distributing an embargoed release that remediates a vulnerability whose disclosure date is scheduled for October 27. https://github.com/BerriAI/litellm/issues/47826 oh boy. Announcing that there's a private enterprise repo you should be paying for if you don't want a credential stealer in your build is quite the optic, and then announcing there's an undisclosed second vulnerability that's being distributed, just not to the poors... |
|
| ▲ | sullivanmatt 3 hours ago | parent [-] |
| That's not what's being said, at all. They are simply telling their enterprise customers that there is a different build pathway for the enterprise builds and that pathway wasn't impacted by this issue. Also if you don't like organizations fixing vulns without releasing the open source first, you're going to be upset when you learn how every major vuln and associated patches are distributed long before the fixes hit the repos. A timely example of this is PHP, literally today. |
| |
| ▲ | petesergeant 3 hours ago | parent [-] | | > A timely example of this is PHP, literally today. Sorry, there was a paid-for PHP release that fixed it I could have gotten a week ago, and that they publicly announced existed, and it was just people who don't pay for PHP who had to wait...? | | |
| ▲ | sullivanmatt 3 hours ago | parent [-] | | Yeah, that's how many companies with open ecosystems work. If you're using e.g. RedHat, you are getting packages with embargoed fixes baked into them before those fixes hit public repos. Node.js, OpenSSL, Git itself all do this. You can argue about whether the "publicly announced existed" part since they don't advertise for any single package, but that's the ecosystem you buy into. | | |
| ▲ | petesergeant 2 hours ago | parent [-] | | > If you're using e.g. RedHat, you are getting packages with embargoed fixes baked into them before those fixes hit public git repos. The way you've written this is substantially misleading. RedHat receives notice of the vulnerabilities so they can prepare packages to be available the moment the embargo lifts, which I guess technically could hit the public packages a tiny bit earlier, but they are not releasing fixes of embargoed vulnerabilities to their commercial clients before the embargo lifts. This is substantially different from the policy I've quoted that I am objecting to. |
|
|
|
