Posts
167
Following
76
Followers
2080
repeated
@jarkko "They all do different things, but yet are alike, and none are real, yet all directly control how the system works. Use them at your own risk as touching almost anything in them is a sure way to crash your system."

:)

Any job that asks you that type of question is just trying to mess with the applicants, stay away from that type of place as much as possible.
0
0
3
repeated

@drewdevault I think I can save you a step here, we did a research paper on this a few years ago.

"Do Software Developers Understand Open Source
Licenses?"

https://www.cs.ubc.ca/~murphy/papers/licensing/software-licensing.pdf

To my chagrin my co-authors overruled me, but in my first draft the abstract was just:

"Nope."

0
7
2
repeated
For your Sunday reading: https://arxiv.org/pdf/2402.05212.pdf "An Investigation of Patch Porting Practices of the
Linux Kernel Ecosystem" in which different distros, and Android, are evaluated as to how up to date they stay with upstream fixes. Note that RHEL or CentOS is not evaluated "because of the lack of public git repositories or insufficient data."

About time someone started writing papers about this stuff...
2
13
31
repeated
@liskin @oleksandr having everyone introduce themselves with the distro they use sounds about like the right kind of silly to me ;)
0
1
6
repeated

We're at the @openssf !

Our mission is to ensure the security of open source software for all.

Are you a seasoned Technical Program Manager excited about and who wants a full-time ?

Apply: https://openssf.jobboard.io/jobs/314008394-technical-program-manager-at-openssf

0
3
0
@vegard @ljs @kernellogger @larsmb @pavel "security impact" means you have to take into account your specific use case, and we have no idea what your use case is Remember, Linux is in cow milking machines, servers, helicopters on Mars, phones, utility meters, watches, mega-super-yacht-stabilizers, wind turbines, printers, cars, planes, trains, and more. Doing an accurate "security impact" is going to be different for all of those cases.

To quote Ben Hawks, "It's hard to capture the fact that a bug can be super serious in one type of deployment, somewhat important in another, or no big deal at all -- and that the bug can be all of this at the same time. Vulnerability remediation is hard."

His full post is worth reading: https://blog.isosceles.com/what-is-a-good-linux-kernel-bug/
4
6
13
@larsmb @vegard @pavel @kernellogger I find it hard to understand how this is an "attack", when it was specifically authorized and endorsed by the CVE employees and board of directors? They knew exactly how many CVEs we would be filing on a weekly basis and how we would be evaluating them for inclusion. We went through many meetings and discussions before our application was accepted and our id submissions were allowed.

They also asked us to backfill the database with our previously submitted GSD information, as well as everything that gets merged forward. That backfill work is ongoing and is the large volume of what is currently being assigned right now. That information has already been out there for years in GSD, putting it in CVE doesn't change the actual kernel commits or "security" at all, it's just that you might not have noticed the GSD entries (hint, the "bad guys" sure did...)

The number of "new" CVE entries is a small % overall as we really have only processed the changes from v6.7.0..v6.7.3 or so. We are behind in the new stuff and will catch up soon there, help is always appreciated, if you see a commit you want assigned a CVE, just ask!

As others have said, this hasn't changed how the kernel commits are merged at all, it's just calling stuff out that everyone should have already been looking at and merging already, with way more meta-data and information than has ever been done before for kernel CVEs, thereby actually raising the information level in the CVE database here (which is probably why the CVE board wanted this.)

If companies are somehow dictating that they MUST look at and evaluate all CVEs, then they should be happy as many groups were intentionally abusing the CVE process for the kernel previously, making their life much more difficult (including the community's life, which is why we became a CNA.) That abuse has now stopped, to be replaced with a different workflow with way more meta-data produced to help make decisions easier. So far one of the biggest complainers was the company that was doing that abuse as they are no longer allowed to do that (to be specific, that was NOT SuSE).
2
14
22
@vbabka Hey, we get some wrong, I thought this was a real "BUG" output, which would have deserved a CVE. Now rejected, if you notice us messing things up at times, let us know! We've already rejected a bunch, here's our current stats after just a few weeks doing this:

Year Reserved Assigned Rejected Total
2019: 47 2 1 50
2020: 37 13 0 50
2021: 45 205 0 250
2022: 45 5 0 50
2023: 51 145 4 200
2024: 502 48 0 550
Total: 727 418 5 1150

Majority so far is back-filling in from the GSD entries. We've only really done 2-3 stable releases so far, we have a bunch of review to catch up with, you can see the current status in our git repo if people are curious what is being discussed/reviewed.
0
1
3
repeated
@clacke @joshbressers @kurtseifried @ljrk Yes, that is a good overview, and you can point at the managers and developers on the Google Android team for doing all of this hard work both in convincing people that this was a good idea, and actually doing the work to get stuff merged properly. I've watched them do this for the past 10+ years, it wasn't easy but has paid off a lot in my opinion, the security level of an Android device is worlds better than it used to be because of this effort.
0
0
6
repeated
I feel terrible, but I haven't laughed this hard in a long time.
8
27
67
@gromit @kernellogger @matttbe #kernelnewbies is great, I've been on there for a _very_ long time.
0
0
3
@sj @kernellogger @kees Oops, need to fix that up, the repo is now handling "live" data, that is a hold-over from when it was just testing data...
0
0
3
@kees What @kernellogger said, I would love to see patches sent for the stuff we have there!
0
0
6
@matttbe @kernellogger We've been on irc for decades, we are everywhere :)
2
0
2
@ljrk @joshbressers @kurtseifried The core Android portion of Google is very much NOT out-of-tree, they merge their code upstream almost always first before applying it to older Android kernel branches. See the yearly report at the Linux Plumbers conference for the past 5+ years where they what has been merged, what is left to be merged, and what is coming next, with pretty graphs and the like.
They have a strong "Get your changes upstream first" rule with their OEMs and you can see the interactions with those companies uptream has increased dramatically over the past years been because of this.

ChromeOS portion of Google also has a strong "upstream first" rule, and is very good about taking updates and getting changes merged properly.

The Pixel out-of-tree stuff is due to other "reasons", but that is a separate division and there have been many patch submissions recently upstream to resolve that delta, so that is being whittled down.
2
0
4
Show older