Conversation
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?
4
6
13
@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?
2
0
0

@gregkh @captainepoch this is probably only visible to repo admins (because security issues shouldn't be disclosed publicly or something). also i did a quick web search and found the docs https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning

1
0
0
@gregkh Same, 404 (screenshot attached).

And related to the issue itself, it might, but I wouldn't know. I think I could turn off this feature from the repo's settings. At least I don't receive any code scanning from any of my repos.
1
0
0
@captainepoch Ok, sorry about that. I'll respond to the original with the full error message...
0
0
0

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.
0
0
1
@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.
2
0
0

@gregkh your last toot showed errors in meson generated files so maybe delete the Build step from the codeql workflow? i'm not sure why exactly you'd want that in static analysis. though there must be some reason the original author put it there so i'm not too sure either way.

2
0
0
@gregkh @tbodt One of the reasons I disabled everything related to code scanning in my repositories.
0
0
0
@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...
0
0
0
@tbodt Oh, nice, let me attempt that...
1
0
0
@tbodt Nope, didn't work. Or I got the yaml wrong, which is probably the real reason here...
1
0
0

@gregkh wrong paths-ignore! in fact i don't think that yaml dict takes paths-ignore at all. it goes in the with: under initialize codeql, but not directly, instead you have to have a config: key whose value is a **string** containing yaml containing paths-ignore https://github.com/github/codeql-action/blob/a1695c562bbfa68dc5ab58c9b5e9f616b52bf5be/init/action.yml#L80

1
0
0
@xexaxo Yes, thank you! And thanks for the PR, I'll go merge that now and see how it goes.
0
0
2

@tbodt @gregkh implementation of path-ignore is language dependent - see issue 1583.

It's a bit odd if you ask me, although as they say "don't look gifted horse in the mouth" 🫣😅

0
0
0
To followup up on this, @xexaxo sent a pull request to get rid of these "code in the meson temp files are security issues" false-warnings: https://github.com/gregkh/usbutils/pull/211

Many thanks for this, now to whittle down the other pointless `switch case is too big` and `FIXME is left in a comment` warnings that are left so that if anything "real" ever shows up, it will actually be noticed...
1
0
7

@gregkh you are welcome.

Admittedly there are some very long/repetitive fragments that can be factored out. But at least it's easier now to look for genuine issues.

0
0
0