Greg K-H
Posts
273Following
88Followers
2844
Greg K-H
gregkh
@bert_hubert Bert's talk is all the more important when you combine it with stuff like this: https://www.propublica.org/article/microsoft-solarwinds-golden-saml-data-breach-russian-hackers
RE: https://mastodon.nl/@bert_hubert/112608731406238492
RE: https://mastodon.nl/@bert_hubert/112608731406238492
0
2
2
Greg K-H
gregkh
@kernellogger @z3ntu Please note that the employer of the linux-next maintainer graciously allows them to do this work on company time because they value it. Perhaps other companies should also allow their developers to help out with this (note, at least one does, so Stephen isn't always alone here)
And we are allowed, and in some places, required, to go on vacation, so a few weeks off isn't going to really stall anything, we all have other ways of testing integrations, so don't worry :)
And we are allowed, and in some places, required, to go on vacation, so a few weeks off isn't going to really stall anything, we all have other ways of testing integrations, so don't worry :)
1
6
18
@pavel @Di4na @camdoncady @dangoodin @joshbressers @kurtseifried Pavel, the very next sentence in the text says "This leads to system crashes and other undefined behaviour."
{sigh}
You are now blocked.
{sigh}
You are now blocked.
1
0
1
@kurtseifried @anant @joshbressers @adamshostack @camdoncady @dangoodin Thank you for noticing, I spent a lot of time on making this information able to be created automatically as it is quite valuable for people to be able to EASILY, and programatically, determine if they should, or should not, even look at this specific entry. Everyone does actually know what small % of the 80,000+ files in the kernel they build into their image, and what versions they are running, right? If not, they have bigger issues than random CVE entries...
Side note, I create all the json from a set of wonderfully horrible bash scripts that parse the semi-free-flowing kernel git commit logs and branches to determine the information needed:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/dyad
https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/id_found_in
Side note, I create all the json from a set of wonderfully horrible bash scripts that parse the semi-free-flowing kernel git commit logs and branches to determine the information needed:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/dyad
https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/id_found_in
0
2
8
Greg K-H
repeated
repeated
@camdoncady @dangoodin @gregkh @kurtseifried @Di4na I cover that and many other things in this blog post
https://opensourcesecurity.io/2024/06/03/why-are-vulnerabilities-out-of-control-in-2024/
2
1
1
Greg K-H
repeated
repeated
Bert Hubert NL 🇺🇦🇪🇺
bert_hubert@mastodon.nlOver vorige post, je kan ook zeggen dat het kabinet "geen grip heeft op de migratie" (naar de cloud). https://berthub.eu/articles/posts/de-hele-overheid-naar-de-cloud-dat-is-een-politiek-besluit/
0
1
0
Greg K-H
gregkh
@lkundrak @mcepl @mort @joshbressers @ljs @vbabka What, you want people to slow down and NOT fix vulnerabilities? Or just not report them like we had been doing for the past decades?
All other operating systems are in the same boat, either they are not actually fixing things, or they are not reporting them. You ask them which it is...
All other operating systems are in the same boat, either they are not actually fixing things, or they are not reporting them. You ask them which it is...
1
0
0
@ljs @joshbressers @mcepl @mort @vbabka It's not a yes/no answer, that's not how the world works. One can hate the system but know that one must work within the system if one wishes to create change for the better. Much like we did for Linux adaption in the first place.
If you don't like CVEs, wonderful, just ignore them, they aren't causing you any issues. If you do like CVEs, great, I have loads of them for you :)
Again, the way CVEs for the Linux kernel were being allocated was broken and being abused by many corporations. We have now fixed that by hopefully making it work for _everyone_ who cares about CVEs, not just the few in the past that were taking advantage of it for their own gain. That is not "trolling", that is "working to fix the broken system that was previously in place".
If you don't like CVEs, wonderful, just ignore them, they aren't causing you any issues. If you do like CVEs, great, I have loads of them for you :)
Again, the way CVEs for the Linux kernel were being allocated was broken and being abused by many corporations. We have now fixed that by hopefully making it work for _everyone_ who cares about CVEs, not just the few in the past that were taking advantage of it for their own gain. That is not "trolling", that is "working to fix the broken system that was previously in place".
5
0
2
@ljs @mcepl @mort @vbabka Yes, I said "trolling" many years ago in jest as there was no way for the kernel community to actually create CVEs like that, it was a joke.
But what I'm saying now is that I am NOT trolling anyone. The number of CVEs created for the kernel is exactly what cve.org wants us to do here as now we ARE allowed to be a CNA. And by being a CNA, we must follow the rules of cve.org which is what we are doing. I have had many meetings with the cve.org employees and board about this, and everyone seems to be in agreement that what we are doing now is correct and should be done this way.
Again, I'm not trolling anyone, and again, the kernel development model has not changed, all that has changed is that finally we are marking all potential vulnerability fixes as CVEs.
Again, if anyone knows of any CVE entries that we have assigned that should not be CVE entries, please let us know.
But what I'm saying now is that I am NOT trolling anyone. The number of CVEs created for the kernel is exactly what cve.org wants us to do here as now we ARE allowed to be a CNA. And by being a CNA, we must follow the rules of cve.org which is what we are doing. I have had many meetings with the cve.org employees and board about this, and everyone seems to be in agreement that what we are doing now is correct and should be done this way.
Again, I'm not trolling anyone, and again, the kernel development model has not changed, all that has changed is that finally we are marking all potential vulnerability fixes as CVEs.
Again, if anyone knows of any CVE entries that we have assigned that should not be CVE entries, please let us know.
1
2
7
@vbabka @mort @ljs @mcepl I am not trolling anything, I am working within the requirements of the CVE system at the request of the people who run it. We are doing so because other entities were abusing the CVE system for the Linux project in the past, so in order to take control of it, we must work within the constraints with which we are placed.
And that means assigning CVEs to everything that meets the definition of vulnerability as defined by cve.org. If you, or anyone else notices a CVE we issue that does NOT meet that definition, please let us know and we will be glad to reject it.
Odds are other operating system kernels will start doing the same as Linux does, if they wish to be a CNA for their project. We aren't alone here, it's just that we report our fixes, others don't, or aren't actually developing any fixes. You be the judge of which is the case for various projects :)
And that means assigning CVEs to everything that meets the definition of vulnerability as defined by cve.org. If you, or anyone else notices a CVE we issue that does NOT meet that definition, please let us know and we will be glad to reject it.
Odds are other operating system kernels will start doing the same as Linux does, if they wish to be a CNA for their project. We aren't alone here, it's just that we report our fixes, others don't, or aren't actually developing any fixes. You be the judge of which is the case for various projects :)
3
5
16
Greg K-H
repeated
repeated
Morten Linderud
Foxboron@chaos.socialOf course it has. CVE identifiers have been misinterpreted/misused/misunderstood this way for years.
1
1
2
Greg K-H
gregkh
@GrapheneOS Nope, that's not why LTS merges are being done slower in the Android kernel trees, there are a variety of other external reasons why that has slowed down. Nothing to do with my CNA work, sorry to spoil your narrative.
You know, a simple email asking "hey, why is this going slower" could have solved all of this speculation...
You know, a simple email asking "hey, why is this going slower" could have solved all of this speculation...
1
0
4
@kurtseifried "Message-ID: <51D1F685.5050608@redhat.com>" should give you a hint of what to search for...
0
0
1
Greg K-H
gregkh
@sageofredondo @ljs @kernellogger @sandeen @vegard Android kernels provide a kABI guarantee as well, and have been taking the LTS releases for many many years now (using the tools that a RH developer helped create to ensure a stable kABI, and contributing to them to make them better for you to use as well), so that's really not a valid reason to refuse stable updates, sorry :)
0
0
1
Greg K-H
gregkh
@somenxavier Sorry, but that doesn't make any sense, udev is part of systemd and has been for a very very long time. If you have udev questions, please ask them on the systemd mailing list.
1
0
0
Greg K-H
gregkh
@vegard @kernellogger "a team of engineers" COULD do that (hint, Android does, by just taking the stable updates), but the paper shows that a specific "team of engineers" currently does NOT do that, which puts the users of those kernels potentially at a greater risk.
Read the paper, it's interesting.
Disclosure, I read it before it was published, but had no influence on it at all.
Read the paper, it's interesting.
Disclosure, I read it before it was published, but had no influence on it at all.
2
1
5
Greg K-H
repeated
repeated
Thorsten Leemhuis (acct. 1/4)
kernellogger@fosstodon.orgJeremy Allison writes:
'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"
https://ciq.com/blog/why-a-frozen-linux-kernel-isnt-the-safest-choice-for-security/ #LinuxKernel
7
6
1
Greg K-H
repeated
repeated
Programming Quotes
programming_quotes@mastodon.socialGet out of the way of your developers or lose them to someone who will.
— Adrian Cockcroft
0
2
1