Posts
290
Following
87
Followers
3123
repeated
repeated

Bert Hubert NL 🇺🇦🇪🇺🇺🇦

Over 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
@ljs @joshbressers @lkundrak @mcepl @mort @vbabka What we are issuing meets the cve.org definition of "vulnerability" as defined by them.

Perhaps you are thinking the word means something different than it does in this context.
1
0
1
@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...
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".
4
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.
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 :)
3
5
16
repeated

@mort

Of course it has. CVE identifiers have been misinterpreted/misused/misunderstood this way for years.

1
1
2
@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...
1
0
4
@vbabka @itaru It was not me, it was Linus over a year ago and I acked the change, as did the LF head of legal, see the commit log text for more information about it: https://git.kernel.org/stable/c/d4563201f33a022fc0353033d9dfeb1606a88330
0
0
3
@kurtseifried "Message-ID: <51D1F685.5050608@redhat.com>" should give you a hint of what to search for...
0
0
1
@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
@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
@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.
2
1
5
repeated

Thorsten Leemhuis (acct. 1/4)

Jeremy Allison writes:

'" The data shows that “frozen” vendor 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 created by Greg Kroah-Hartman. '"

https://ciq.com/blog/why-a-frozen-linux-kernel-isnt-the-safest-choice-for-security/

6
6
1
repeated

Get out of the way of your developers or lose them to someone who will.

— Adrian Cockcroft

0
2
1
repeated

I just got a few ideas for the next idiotic DMCA takedown notice I have to respond to...

https://bsky.app/profile/cola.baby/post/3ksffq2k5kb22

1
2
0
@sima @kees @kernellogger I'll gladly assign more, just send me git ids and we can do the rest :)
2
0
2
@kees @kernellogger Most of the rejects are not "false positives" but rather "Duplicate ID issued due to some company not putting git commit ids in their CVE records so we didn't know not to create this entry."

At least that's what is happening so far on all the rejects in 2023 and older, for 2024, those are actual "false positives" so our numbers look higher than I imagined. Maybe no one is paying attention, which could also be the case...
1
0
3
@kernellogger Well, some of those 1000 have been rejected, here's the current stats that anyone can check for themselves in our public git repo by running `scripts/summary` so you don't have to hack up fun `find | wc` chains like you did:

Year Reserved Assigned Rejected Total
2019: 47 2 1 50
2020: 37 13 0 50
2021: 39 304 7 350
2022: 7 43 0 50
2023: 60 180 10 250
2024: 107 435 8 550
Total: 297 977 26 1300


Anything older than 2023 is us back-filling in from the GSD database, and we still have a long way to go for there. Some 2023 ones are in there too from GSD, but mostly not, all of 2024 is since we took over being a CNA.
2
3
8
Show older