Re: Concerns about how the Security information is presented on Debian.org
Dear Andrew,
My critique is NOT of how the Debian project manages updates in Stable. It's of the decision not to inform the users of the inherent limitations of Debian's approach, which I believe is a violation of the social contract.
Let me make some concrete proposals for debian.org/security
1. Remove the current content, especially where it implies things that are untrue or can be misinterpreted (providing fixes for all known vulnerabilities in all packages in Debian)
2. Remove the red herring about "security through obscurity". Not only is it not relevant for someone choosing between Stable and Unstable, but it's also untrue. BSDs have a rep for being secure, but one auditor found 100+ vulns in 90 days in his spare time (1). I challenge anyone to do the same without looking at the code, for any OS.
3. Inform the users that using anything but the latest version of the kernel (2) and other packages comes with inherent risks and explain them (delays in backporting fixes and known vulnerabilities not being disclosed)
4. Specifically explain the situation with Chromium (which is sad, BTW, because Chrome/Chromium is considered safer than Firefox, despite having more CVEs)
5. Have a sentence like "Debian Stable includes X-many packages, of these Y% have outstanding reported vulnerabilities, with Z per package, on average", or better yet a table that breaks this down by Debian's version and repository (This could just use the data from the security-tracker)
(1) https://www.youtube.com/watch?v=rRg2vuwF1hY (I don't want to side-track my own thread into talking about BSD. Just making a point that all current content verbiage should be deleted)
(2) https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html
Quoting from the above:
"... given the volume of flaws and their applicability to a particular system, not all security flaws have CVEs assigned, nor are they assigned in a timely manner. Evidence shows that for Linux CVEs, more than 40% had been fixed before the CVE was even assigned, with the average delay being over three months after the fix. Some fixes went years without having their security impact recognized. "
"If you're not using the latest kernel, you don't have the most recently added security defenses (including bug fixes). In the face of newly discovered flaws, this leaves systems less secure than they could have been. "
Google Security Blog is talking about the kernel, but the same logic applies to other packages.
--
Sent with https://mailfence.com
Secure and private email
Reply to: