lmao that copy.fail was in linux/crypto/
Post
Replies:
6
Boosts:
6
we all know that "AI" can't find vulnerabilities, and having a legit vulnerability is not a proof that "AI" found it. instead it means it was already known beforehand. why someone would choose to release it publicly then becomes the question at hand
the fact that it wasn't responsibly disclosed means the "AI" corp isn't interested in being seen as a legitimate security corp. and it does force people to frantically update without thinking or auditing much
which is what you would want if you had inserted a backdoor into linux/crypto/ during the 7.0 rc cycle
this makes me feel very nihilist and i don't need more proof but it's useful to identify the patterns which may be used to insert backdoors. i absolutely 100% called in advance that there would be vulns declared right after the 7.0 release because of the backdoor i found
i don't think it's worth getting upset over this because the only way to fix this is to develop not just code which is safe against backdoors (i think a microkernel is the correct approach to start off with) but also a governance model that achieves accountability processes so that this can't be hidden (and then a retro process that identifies architectural improvements)
a "blameless postmortem" exists because internal corporate politics seek to use blame to avoid fixing issues. there are ways in which this can be valid in other contexts, but codebases that seek to achieve security for their users generally don't have internal politics to deal with and instead very much do have to worry about trust and accountability for failures
