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 an hour 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 an hour 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 an hour 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.