staticassertion

7 ms·

61.
by staticassertion 5mo ago
In the infosec world, it pretty much is where the popular discourse has always been. It's just a bunch of nonsense terminology.
62.
by staticassertion 5mo ago
You can see my other comment on this. The word "obscure" is not very relevant to the phrase "security through obscurity".
63.
by staticassertion 5mo ago
You're overly focusing on the term and not the meaning. The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because
64.
by staticassertion 5mo ago
It's a very strong, plainly stated assertion that contradicts stated goals of the project so it seems like it deserves supporting evidence. Editions exist to avoid breaking code over time.
65.
by staticassertion 5mo ago
This isn't about what's a good idea or bad idea. Perhaps it's best to simply leave analogies behind, otherwise we'll just focus on the wrong thing. Security through obscurity merely means that your system is atypical. It
66.
by staticassertion 5mo ago
No, because ASLR uses a secret.
67.
by staticassertion 5mo ago
I don't think that really works because obscurity isn't harder to see or find. I don't know the analogy, it's like standing out in the open and being like "yeah but who would think to look here lol".
68.
by staticassertion 5mo ago
> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. That statement deserves support.
69.
by staticassertion 5mo ago
No, that's the correct URL.
70.
by staticassertion 5mo ago
He's full of shit lol
71.
by staticassertion 5mo ago
Sorry but he literally doesn't and nothing you say is going to change that he has explicitly stated that. This isn't up for debate, go ask him yourself, literally go to the first blog post on his site. As for the latest patch, Gre
72.
by staticassertion 5mo ago
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen... I'd start with Greg's own words. You can probably find more on it from Spender/grsecurity's blog.
73.
by staticassertion 5mo ago
Why would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.
74.
by staticassertion 5mo ago
I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?
75.
by staticassertion 5mo ago
> I wonder when Linus will see sense. Literally never. Why would he? He's surrounded by sycophants. And we have Greg for whenever Linus isn't involved anymore, and Greg is just as boneheaded.
76.
by staticassertion 5mo ago
This couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this. The reason they don't is because Linus and Greg have repeatedly, publicly stated tha
77.
by staticassertion 5mo ago
Yes.
78.
by staticassertion 5mo ago
Greg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, d
79.
by staticassertion 5mo ago
That's mostly on Greg, a bit on the author.
80.
by staticassertion 5mo ago
The patch was available. Upstream just doesn't communicate vulnerabilities because they have a personal dispute with distros about how to handle patching.
81.
by staticassertion 5mo ago
In a just world, those companies would be held legally accountable for negligent practices. The Linux kernel upstream has made it clear for decades that security is a dirty word. LPEs on Linux are obscenely commonplace.
82.
by staticassertion 5mo ago
> they are in a much better position to coordinate and communicate with the maintainers than random reporters are. They openly refuse to do this and have been given authority by MITRE to work against any such process.
83.
by staticassertion 5mo ago
That's fine and a very separate reason why it would not be exploitable, also assuming that the module is not just compiled in since then loading it would be irrelevant.
84.
by staticassertion 5mo ago
I think sysadmins should learn the term LPE tbh
85.
by staticassertion 5mo ago
Where would you have them write a detailed report if not a website?
86.
by staticassertion 5mo ago
The specific exploit payload for the POC relies on a su binary. The vuln is ambivalent and other non-su paths will exist.
87.
by staticassertion 5mo ago
To be clear, I'm not suggesting that you if have heard of CVEs therefor you must have heard of LPE. I'm saying if you have read many of them you would have seen these terms. I obviously do not expect someone who has merely heard
88.
by staticassertion 5mo ago
I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.
89.
by staticassertion 5mo ago
I assume that wouldn't help here but I could easily be wrong. (Assuming if you're asking if SELinux would block this exploit).
90.
by staticassertion 5mo ago
The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even w

More ›