@tbodt codeql really wants to build the code, as I'm guessing it is doing so with a compiler hack to get at the files needed to analyze. I guess we can turn that off, let me try that out...

@tbodt @captainepoch Yes, enabling it is good. Stupid tests claiming problems that are not actually present at all are not good.

Drowns out any potential real issues.

As it turns out that “code scanning” isn’t public, here’s the error message that github is putting up saying that meson temp build files are security problems:

build/meson-private/tmpzhj7u8eq/testfile.c:2  Test

Poor global variable name 'i'. Prefer longer, descriptive names for globals (eg. kMyGlobalConstant, not foo).

Rule ID cpp/short-global-name

Description
This rule finds global variables which have a name of length three characters or less. It is particularly important to use descriptive names for global variables. Use of a clear naming convention for global variables helps document their use, avoids pollution of the namespace and reduces the risk of shadowing with local variables.

@captainepoch Ok, sorry about that. I'll respond to the original with the full error message...

@captainepoch Odd, works for me!

How about this https://github.com/gregkh/usbutils/security/code-scanning

And it's obviously picking up the temp files that meson uses for "does this compiler have this feature" but that's temp files, and not actually in the repo itself. Surely tools like meson are handled properly, right?

Dear lazyweb,

For the usbutils project, developers have helpfully set up a bunch of github actions to help with build tests and the like, and it also includes github's "security scanning" toolsets. Unfortunately the output of such tools is pretty useless and unhelpful to a fault.

Example, this "result": https://github.com/gregkh/usbutils/security/code-scanning/2291
which claims "short global name" yet there is no such actual global variable `i` in the codebase at all.

Because of stuff like this, the tools "claim" there are 63 "security" issues in the usbutils project. Since when did using single character names become a security issue, even if we were doing that, but ok...

So, how to turn this off, or better yet, fix the test to not report issues that are actually in the tests themselves?

@kernellogger @mxk Totally understand.

Here's a link to Todd's latest Plumbers conference calling out how they are going to support devices for 7+ years by moving to new kernel versions over time: https://lpc.events/event/18/contributions/1703/attachments/1391/2998/LPC%202024%20-%20Android%20Device%20Longevity.pdf

@kernellogger @mxk That's not how Android kernels are working anymore. Vendors can have huge numbers of external kernel drivers/modules (i.e. pixel 6 has 300+ of them), but the "core" kernel is managed by Android/Google, in public, in their GKI kernel branches, and that is what is the "base" of the kernel that all vendors can then add drivers to.

If a vendor wants to change the "core" parts of the kernel, they must either submit the changes upstream for merging first (and then backport the change to the GKI kernel and submit it to Android), or somehow convince Android to take it into their GKI kernel (with reasons why upstream rejected it), or add a "hook" to the GKI kernel so that they can put their changes in a kernel module (like many do for scheduler changes.)

The -lts releases get merged into the Android/GKI kernel branches on a monthly basis, which then gets pushed out to all devices "quickly" as there are no in-kernel-abi breaks between the GKI kernel and all external kernel modules used by vendors.

Android has followed the "old" enterprise kernel module here, with the exception of the hook additions, that companies have used for decades (the abi stability changes were taken directly from RHEL and SLES). It's not exciting kernel work, but allows security fixes to get pushed out to devices MUCH faster which is helping everyone out, AND it has forced the vendors to work upstream to get their features merged properly, which has been happening for years now to much success.

There was a plumbers talk all about this this year (and last, and the year before), if you want more details.

@tusooa Heh, you're trying to convince a "Russian identified person" in one of the senior positions in the Linux Foundation that the Linux Foundation is being unfair towards "Russian identified people." It's pretty hilarious.

I'm not a lawyer and I don't speak for the LF, so I won't give you any kind of "official comment." But here's my view of it.

The people removed from maintainer positions were identified as employed by companies on the US and EU sanctions list. These companies are directly involved in the Russian military complex and therefore are directly complicit in war crimes being committed daily in Ukraine. If these maintainers want to think that they are "just techies helping improve the Linux kernel," or that "they are outside of politics," then they are fucking wrong. If they work for companies that develop weaponry or logistics used by the Russian military, they are complicit in Russia's war crimes, and I hold them responsible at a very personal level -- and that's my official comment on the situation.

#usbutils (which contains lsusb and the more modern lsusb.py) 018 is out:

https://lore.kernel.org/all/Zxd0oZefuehqhA7z@kroah.com/

@gregkh writes:

'"For users, the largest change will be that the '-v' option to lsusb will now show the negoitated speed of the device on the bus […], and there is better handling for new device descriptor fields and information in the '-v' output as well."'

@kernellogger And that is why the AUTOSEL bot exists.

@kernellogger NP, and odd that no one actually tagged that commit to be backported to stable kernels... {sigh}

Then here came @gregkh talk about CVE and Rust (see 39:42):

"Rust is going to help us. It'll fix up all the error handling bugs. When you do bad things in memory it just reboots the box... You will get CVE but you won't be able to make a vulnerability out of it."

https://youtu.be/bf3MYWtI4E4?feature=shared

@kernellogger I'll go pick it up for stable/LTS trees now, don't worry :)

For open source people, I recommend reading this fine post from @nlnetlabs / @maarten -> https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/ and you might also get some benefit from https://berthub.eu/articles/posts/eu-cra-recitals-comments-compiler-judge/ if you plan on reading the actual act -> https://data.consilium.europa.eu/doc/document/PE-100-2023-INIT/en/pdf 2/2

So… O’Reilly sent me email today hyping up how my books (really, just the one, I assume) is going to be AI-translated into Spanish and German, with other languages to follow. This was probably inevitable, but I still have concerns.

First: are there no human translators of these languages?

Second: who’s going to proof-read all 1,126 pages to make sure nothing got botched, especially given the technical nature of the content? The readers? Which isn’t even crowd-sourcing: it’s customer-sourcing.

@hikari What firmware blobs? The old ones were all in text format anyway (arrays of bytes in a .c or .h file), so that's never really been an issue. I think they are almost all gone from the tree now so that shouldn't be an issue.

For the linux-firmware project, you can send binary diffs to them, in email, git handles that just fine. You aren't reviewing a binary file anyway, it's either you take it or you don't.

@hikari @mcepl @koopa Linux doesn't have binary files in its source tree (for the most part, there are a few tiny exceptions), so this isn't an issue at all.

@hikari @mcepl @koopa Agreed, and for smaller projects, gerrit is almost even nice to use, but for ones with any "real" amount of size of developers and rate of change, it is rough and I curse it every time I have to review a kernel patch series in the Android gerrit instance :)

@hikari @mcepl @koopa "well" is "better than any other web-based workflow" yes, gerrit does handle them better that way.

But no way is it better than an email-based review workflow, whereby I can just tear through hundreds of patches in a very short amount of time, all while sitting behind a very slow/laggy internet connection, or totally disconnected (i.e. better for distraction-free work).

As almost no other project is at the rate of change or size of the Linux kernel, gerrit might be wonderful for your smaller one. But for ones that are our size, realize that centralized workflows like gerrit and the like just do not scale at all.