Recent searches
Search options
Administered by:
@mcepl That's not what I'm saying. I'm saying that if there are enough exploitable vulnerabilities in Linux to fix a hundred of them every single day consistently, clearly it's not a very secure operating system
If there's not enough exploitable vulnerabilities to do that but they're publishing a hundred CVEs per day regardless, that's just a DDOS attack against a deeply imperfect yet useful vulnerability reporting system
And yet until yesterday you were using it happily persuaded that it is secure, and if Greg took over FreeBSD and start reporting CVEs on it, you would be persuaded that it is insecure as well? It is just reporting!
@mcepl Well I knew there were issues, nothing is perfect, but I was under the impression that it was secure enough that you couldn't fix a hundred exploitable vilnerabilities per day and still go strong a month later, yeah.
@mcepl If FreeBSD started publishing a hundred CVEs about exploitable vulnerabilities per day I would have the same reaction to that
@mcepl@floss.socialHave you watched https://youtu.be/HeeoTE9jLjM ?
@mcepl Maybe, I can't recall and I don't think it's very relevant.
And of course @BrodieOnLinux@linuxrocks.online published very detailed analysis of the issue on https://youtu.be/g_yrk7BXLRI
@vbabka @mort @mcepl Honestly I don't really see the point in going over it all again when @gregkh just >/dev/null's people who point out the issues.
As much as I respect the big G, it's not really a conversation if it's one way is it...
Everyone knows the issues, everyone knows it's a troll, but it is what it is :) :) :)
As much as I respect the big G, it's not really a conversation if it's one way is it...
Everyone knows the issues, everyone knows it's a troll, but it is what it is :) :) :)
@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 :)
www.cve.orgCVE Website
@gregkh @vbabka @mcepl @mort everything you say after 'I am not trolling' absolutely does not contradict the position that you are trolling (nor what you said in your talk about... err... trolling CVEs).
Trolling CVE = following the rules to the letter to demonstrate the rules are silly.
I mean I might not be as senior as Vlasta (which is probably why you're replying to him not me), but I did speak to other senior kernel people in person and EVERYBODY thinks this is what you're doing.
The issue are the downstream effects as collateral damage, but since your position is 'use stable kernels or I don't care' I guess you don't care ;)
Trolling CVE = following the rules to the letter to demonstrate the rules are silly.
I mean I might not be as senior as Vlasta (which is probably why you're replying to him not me), but I did speak to other senior kernel people in person and EVERYBODY thinks this is what you're doing.
The issue are the downstream effects as collateral damage, but since your position is 'use stable kernels or I don't care' I guess you don't care ;)
@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.
www.cve.orgCVE Website
@joshbressers @mcepl @mort @gregkh @vbabka Does he answer the question I just asked?
As I feel that's absolutely fundamental (malicious compliance doesn't work if you admit it's malicious compliance).
As I feel that's absolutely fundamental (malicious compliance doesn't work if you admit it's malicious compliance).
@ljs @mcepl @mort @gregkh @vbabka he does explain it
The Linux kernel is one of the most widely used pieces of software on the planet. It’s in phones, space ships, and milking machines
They tag anything they think could be a problem without understanding the use case
As one would expect, this is a very wide net
@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".
@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...
@gregkh @joshbressers @lkundrak @mcepl @mort @vbabka I mean 'demonstrably exploitable vulnerability'.
Many things 'could' be, only a few actually are.
And I think the breadth of CVE's definition is the underlying issue here, as many seem to be under the impression that an issued CVE implies it is a known, perhaps even already exploited issue that therefore must be resolved.
Rather than a fixes: tag assigned to something because you broke an antique system in some obscure edge case
Many things 'could' be, only a few actually are.
And I think the breadth of CVE's definition is the underlying issue here, as many seem to be under the impression that an issued CVE implies it is a known, perhaps even already exploited issue that therefore must be resolved.
Rather than a fixes: tag assigned to something because you broke an antique system in some obscure edge case
@ljs CVE number has never been the thing you are talking about. The whole purpose is to uniquely identify security issues so everyone knows they are referring to the same thing when they communicate. It is a damn good idea to get a CVE number early so you can start using that number in the research and root cause and fix. If you only get it at the end, the record is half lost.
@shironeko where did I say, exactly, that that's what CVE was?
@ljs
> I mean 'demonstrably exploitable vulnerability'.
to demonstrate a vulnerability is exploitable takes months of work and you should get a CVE number before you do any of that to document your process so it's searchable later.
> I mean 'demonstrably exploitable vulnerability'.
to demonstrate a vulnerability is exploitable takes months of work and you should get a CVE number before you do any of that to document your process so it's searchable later.
@shironeko ok will give you 1 more chance to show you're in good faith before I block.
I never said this was what CVE was. You can't point out where I said that, because I didn't.
It's not helpful to jump in and add a false straw man argument to try to make me look silly.
And instead of admitting that, you quote me not saying that... I mean c'mon. :)
I repeatedly said 'this is the whole issue with CVEs' by which to be clear I mean people taking them to mean that rather than the actual definition which is as you say.
I was explicitly explaining what I meant in answer to what Greg asked.
The issue as I have said probably more than once are the downstream effects this stuff has in reality, which is causing harm to people.
Yes the whole thing is broken and stupid, but it's a question of whether this is the right solution.
I never said this was what CVE was. You can't point out where I said that, because I didn't.
It's not helpful to jump in and add a false straw man argument to try to make me look silly.
And instead of admitting that, you quote me not saying that... I mean c'mon. :)
I repeatedly said 'this is the whole issue with CVEs' by which to be clear I mean people taking them to mean that rather than the actual definition which is as you say.
I was explicitly explaining what I meant in answer to what Greg asked.
The issue as I have said probably more than once are the downstream effects this stuff has in reality, which is causing harm to people.
Yes the whole thing is broken and stupid, but it's a question of whether this is the right solution.
@gregkh @joshbressers @mcepl @mort @vbabka I mean I think this is, in different (and more polite perhaps) words, the same as what I and others assumed you were doing :>)
The issue are downstream effects on enterprise kernels where suddenly workloads are increased dramatically.
The focus on CVEs as a measuring tool for this is broken obviously, debate is whether opening the flood gates is the right way to highlight that.
But as I said a few toots ago, I gather your position is 'the stable kernel is what you should be using' (correct me if I'm wrong), so I guess to you this is immaterial.
The issue are downstream effects on enterprise kernels where suddenly workloads are increased dramatically.
The focus on CVEs as a measuring tool for this is broken obviously, debate is whether opening the flood gates is the right way to highlight that.
But as I said a few toots ago, I gather your position is 'the stable kernel is what you should be using' (correct me if I'm wrong), so I guess to you this is immaterial.
@ljs @mcepl @mort @joshbressers @gregkh @vbabka Yes, workloads have increased for enterprise distros (I'm directly affected). But blaming that on GregKH I think is shooting the messenger. Enterprise distros have ALWAYS had a duty to evaluate what they are shipping or not shipping. If anything, the kernel CNA is doing a great job of highlighting exactly how many bugs there are in the kernel.
I proposed that distros could collaborate and got essentially zero response: https://lore.kernel.org/all/20240311150054.2945210-2-vegard.nossum@oracle.com/
lore.kernel.org[RFC PATCH 2/2] doc: distros: new document about assessing security vulnerabilities - Vegard Nossum
@vegard @mcepl @mort @joshbressers @gregkh @vbabka you are doing God's work there honestly!
To me this is the clear way forward - finding some means of SENSIBLY identifying security issues at a granularity customers + regulators can understand and assess.
I think there may be an ongoing educational issue however with customers/govts thinking in terms of CVEs that might be a big stumbling block.
It's less shooting the messenger I think overall (and note, I made sure to always tag Greg in so he could respond!) than asking - knowing the inevitable downstream effects, is this a good way of doing things?
And as to whether it's an intentional effort to try to get this kind of policy change.
I think pretty much it is.
I hope that it ends up being a positive outcome, it's not encouraging that people didn't respond to you there though. But it's great that you made the effort, and I think eventually this is the way forward.
To me this is the clear way forward - finding some means of SENSIBLY identifying security issues at a granularity customers + regulators can understand and assess.
I think there may be an ongoing educational issue however with customers/govts thinking in terms of CVEs that might be a big stumbling block.
It's less shooting the messenger I think overall (and note, I made sure to always tag Greg in so he could respond!) than asking - knowing the inevitable downstream effects, is this a good way of doing things?
And as to whether it's an intentional effort to try to get this kind of policy change.
I think pretty much it is.
I hope that it ends up being a positive outcome, it's not encouraging that people didn't respond to you there though. But it's great that you made the effort, and I think eventually this is the way forward.
@gregkh @vbabka @ljs @mcepl @mort No. You are trying to "burn them" , as you publicly said and is archived on youtube. You are assigning CVE numbers to bugs fixed in -stable kernels, without analysis if they constitute a vulnerability or not, copy/pasting patch title as vulnerability description... That is neither subset nor superset of real vulnerabilities. Plus you are not exactly welcoming when people try to reject an CVE.
@gregkh @ljs @mcepl @mort hmm interesting, afaik curl also became a CNA early this year and a glance at their list of vulnerabilities doesn't look anything like Linux's https://curl.se/docs/security.html so that would mean they are not doing what's expected of them?
curl.securl - CVEs
@MWelchUK @mpe @mcepl @mort @gregkh @ljs didn't mean to just compare numbers, but the curl CVEs from 2024 look like the traditional stuff explaining a vulnerability etc. I'd expect even with the much smaller codebase they had fixes this year applied in git that would get a CVE by the current kernel process, but didn't.