An exploit is already in the wild. What seems irresponsible is not adapting to a new reality.

nicce a day ago | parent | next [-]

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.

	▲	charcircuit a day ago \| parent [-]
		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.

▲

threatofrain a day ago | parent | prev | next [-]

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.

▲

MartijnHols 19 hours ago | parent [-]

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?

	▲	joepie91_ 18 hours ago \| parent [-]
		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.

▲

b112 a day ago | parent | prev | next [-]

No.

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.

And?

You won't be at the table next time.

▲

richwater a day ago | parent [-]

[flagged]

▲

b112 a day ago | parent [-]

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.

▲

nagaiaida a day ago | parent [-]

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?

	▲	benlivengood 21 hours ago \| parent [-]
		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.

▲

shakna a day ago | parent | prev [-]

Was the exploit made, from reverse-engineering, this early release? Because that is how I'd do it.

▲

nagaiaida a day ago | parent [-]

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?

▲

shakna 21 hours ago | parent [-]

The reading that chainguard have said that before when it was not the case.

Why would you implicitly take them at their word?

▲

nagaiaida 19 hours ago | parent [-]

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.

	▲	workingjubilee 18 hours ago \| parent \| next [-]
		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.
	▲	shakna 12 hours ago \| parent \| prev [-]
		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.