What an incredible irresponsible move essentially 0-daying everyone who was working toward coordinated disclosure to ensure everyone had images or distro packages to update to.
Yes but they obtained this information based on the one-sided courtesy of another party, under a scheme that tried to get as many people to safeguard together.
If the first party to receive this information says, "Wow, of course I must act on this, because customers are on the line," then it makes sense to simply choose who you tell more carefully or not at all.
If you saw customer data was being compromised; financial data, government data, electronic patient records etc, and you had the fix. Would you do nothing?
The alternative isn't "doing nothing". It's raising the issue in the coordination group so that everyone can collectively decide on a new timeline if necessary, and you aren't leaving everyone else hanging out to dry.
Publishing a patch beforehand potentially multiplies the impact. Now the actual bug(s) can be diffed from the source. Whereas existing PoCs (after verifying whether it even works), obfuscated at least a bit about the details. It is not so clear what is the best approach.
Yesterday the actual bugs plus many more (though less critical) were discovered by the people pointing their LLMs at it. I am confident no new bugs will be found by looking at binary diffs compared to what was already surfaced.
If you want to 'adopt' a new reality, you talk to all parties, and everyone moves up the release. That's how agreements and trust work. If you don't do so? No one will trust you ever again.
It seems like you don't agree with coordinated releases as a standard. That's fine, but irrelevant here. If you agree to coordinate, so that you can get inside info on security updates and be prepared, and then break that agreement, you're not trustworthy. No hand wavy reasons will change this fact.
I don't know many who want to deal with untrustworthy people.
what exactly is the point of maintaining coordinated disclosure even if one believes in it wholeheartedly in the case where the thing in question is under active exploitation already and there is no longer any hope of quietly solving the issue before active exploitation begins?
are we to somehow count the hypothetical future exploitees that may yet be helped by avoiding disclosure 1–1 against the actual literal current exploitees harmed by further postponing the fixes landing?
The question is where do you spend your trust. If you think that you'll always be able to find and patch 0-days before anyone else into the indefinite future then it's fine to defect.
If you want your customers to believe they won't be hung out to dry when the broader community patches before they can because you're no longer in the loop, you cooperate.
It's not like this is the last 0-day that will need to get patched and deployed in a hurry. "Not slower to patch than
virtually anyone else" is a pretty sustainable place to be.
what possible reading of "I made the call to get these out early when exploits hit in the wild" contorts into "these exploits hit in the wild after i made the call to get these out early" with flipped causality?
sure, i'm happy to recant my rather tepid defense of chainguard in the case that what was said upthread was a blatant fabrication. i'm even open to being convinced that it was.
as it stands though, what i replied to wasn't a useful addition to the discussion. it could easily become so by either being made contingent upon the possibility of that being a lie, or being bundled with an assertion like yours that chainguard is not to be taken at their word. doing neither and simply responding as if a causally opposite statement had been made is just a non sequitur.
I don't think we have to not-believe Chainguard. To me, the problem is more that "in the wild" is a somewhat airy statement that can only be taken to strictly mean that one found it somewhere on a computer that is connected to other computers. This is almost a non-statement, as airgaps are the exception rather than the rule.
Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.
Not a non sequitur - No one should be taken at their word. Not them, not me, and not you. This is the security world. Nobody is trusted altogether.
Breaching an embargo, makes reverse engineering easier. We don't need to analyse motives or pontificate. Disrupting the supply chain... Disrupts the supply chain.
This is nonsense, disappointed to see that publicly from a core dev. Yes, some people are asleep, but the decision was made to wait, to ensure the patch is only made available when users are actually able to install the update and we're giving distros the time to build PHP packages.
reply