The #Linux kernel developers are now issuing their own, more accurate Common Vulnerabilities and Exposures #security bulletins. https://opensourcewatch.beehiiv.com/p/linux-gets-cve-security-business by @sjvn
The Linux kernel developers are now in charge of its Common Vulnerabilities and Exposures (CVE) security problems.
Computer folks, remember the precedence of operators! Consult this handy list if in doubt:
() [] -> .
! ~ ++ --
* / %
+ -
<< >>
< <= > >=
== != &=
=== &&& |||
?: ??= ( ^..^)ノ
(╯°□°)╯︵ ┻━┻
Last time I did a Linux kernel security flaw lifetime analysis was back in 2021. It showed the average time between flaw introduction and fix was 5.5 years for 108 "high priority" CVEs:
https://outflux.net/slides/2021/lss/kspp.pdf
I refreshed my dataset today and was surprised to see that now with 103 more CVEs, it's still holding at 5.5 years. This actually means Linux is getting faster at finding issues, but the (diminishing) technical debt of the past is still dragging down the average.
[$] A turning point for CVE numbers https://lwn.net/Articles/961978/ #LWN
Some weekend stable kernel updates https://lwn.net/Articles/958860/ #LWN
After 4 years the strlcpy() API has been fully removed from the Linux kernel. Long live strscpy().
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d26270061ae66b915138af7cd73ca6f8b85e6b44
Next up, strncpy()!
https://github.com/KSPP/linux/issues/90
"We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value [replacement value for each firm that uses the software] is much larger at $8.8 trillion. We find that firms would need to spend 3.5 times more on software than they currently do if OSS did not exist."
Sequentially in my feed: a toot about the Mars helicopter Ingenuity and its continued flying around, followed by a toot about Linux 4.14 reaching EOL.
Which reminds me, Ingenuity is running a 3.6 kernel. And it has the only excuse I can tolerate for having not been upgraded: it's on a different planet. ;)
UPDATE: Blijkt dat het artikel 73 al sinds 2013 vragen oproept.
Vandaag in het nieuws dat een AIVD agent meegeholpen zou hebben aan het saboteren van het Iraanse kernwapenprogramma. Dit lijkt me uitstekend. Maar politiek Den Haag schijnt van niets geweten te hebben. En dat zou best kunnen, want de AIVD en MIVD mogen agenten dingen laten saboteren zonder toestemming van minister of toetsingscommissie, en dat is raar:
https://berthub.eu/articles/posts/het-curieuze-artikel-73-aivd-mivd/
Ok, Vger's MX is heading off to point to subspace on Thursday. Web services are staying put for now, so if you link to / use Vger it's staying put (possibly with a massive OS upgrade coming).
The fundamental infrastructure isn't going anywhere even if it has to change it's name, and should lists not want to head off to subspace, infradead, etc I've got https://vger.email up and running and capable of picking things up should anyone want to jump.
End of an era, Vger's been independent of kernel.org from it's start, but it's a non-trivial set of lists that literally keep the Linux kernel community moving, and has since it's inception. It's realistically needed an upgrade to deal with a plethora of problems, and frankly various large e-mail providers have made it nearly untenable to keep doing without it nearly being a full time job (at least at the scale that Vger's at)
Dirk: "Are you worried about bugs from LLM hallucinations getting into the #Linux kernel?" Linus: "Well I see all the bugs that come in without LLMs, and so, no I don't." (Paraphrasing the exchange)
A lot of folks are going to have a bad time with this
https://nvd.nist.gov/vuln/detail/CVE-2023-45853
It’s a critical #CVE in zlib
Except it’s not critical
And doesn’t affect zlib
The whole CVE system is too broken to fix