If concrete evidence does not become available resolves PROB to my opinion at close.
Currently I'd put it around 20-30%, mainly due to:
clumsy and unnecessarily public exploit implementation (plus interoperability issues) characteristic of somebody without a team able to build a professional test environment and hammer out bugs
scope well within a determined individual's reach
general lack of corporate feel seen from state actors in the past
I will not trade in this market
@CodeandSolder it took years to get there, that points me to someone that has a lot of time to spend for potential future gains. State actors are a match for that.
Also, you seem to think that the sloppyness/clumsiness is a point against state actors, I don't really see why that would be the case. I would expect state actor devs to be just as sloppy and clumsy as the next guy.
@Odoacre I don't think so, actually, what state actors are known to be interested in is mechanisms for single targeted attacks right now (think Pegasus, Stuxnet) and vast access to large amounts of data (general NSA scope of work), this kind of general backdoor that will be found sooner or later, especially if they actually use it, doesn't seem to fit nicely into this. Plus in most uses an existing tool like Pegasus would be simpler and way more reliable.
And it's not just sloppiness, it's sloppiness that is avoided by structure and organizational knowledge, by having other people to consult on what you're doing. Look at Stuxnet, infected billions of computers, carried out the task and only got detected because of a literally one in a billion accident, not hanging SSH for half a second.
@Odoacre also, this approach means you either have a backdoor in every governmental system that uses Linux and have to hope you didn't mess up the authorization for it (which it seems the XZ exploit did) or have to somehow create a reason to eliminate it without making anybody suspicious, across all branches of government
@retr0id I'm open to arguments, PROB is because I don't want it to became "probably will not resolve", especially with the current loans implementation
@retr0id my main argument against it being a state actor (or even an organized software development team) is all the clumsiness that could be eliminated by throwing resources at the project, the .1 version incredibly suspiciously changing the test files, the 5x performance impact on ssh which could for sure be optimized away, the whole thing looks like one person with a lot of time, not a professional team where you can post "the exploit slows down ssh way too much in the automated tests, can somebody clean this up for me while I finish the plugin integration" or "the build pipeline for Debian fails, who's responsible for that" on Slack
Like, this isn't what you get from an institution
@CodeandSolder problem with this setup is that since it's unlikely there will be any evidence, the best thing to do is to just bet market towards the probability you have stated. Maybe resolve to a poll?
@Weezing this setup has worked well in my previous markets, often ending up far from my initial probability, the poll would need to be somewhat selective to be usable, not sure how to achieve that
I expect there to be new evidence (P~60%) and will observe the expert consensus as it forms.