[00:21] mdeslaur: heh even though I wrote that blog post I had forgotten about unprivileged bpf for impish - in my head I was thinking it was only in jammy :) [00:33] amurray: I've been setting that sysctl key since 2019 and https://lwn.net/Articles/660331/ says it went in kernel 4.4 apparently [00:34] sdeziel: I meant I had forgotten we changed the default to disallow unpriv bpf in impish [00:35] amurray: ah, OK sorry for the confusion and good to know! [15:19] Hi again ebarretto, sorry for bothering again. Regarding what was said yesterday about cvescan, I tried to do a bit of a comparative analysis between that database and OVAL, so here's a couple thoughts: https://pastebin.com/bzJhErQt [15:19] Given these, I wanted to know whether there are some planned improvements for the data provided via OVAL before the cvescan databases are deprecated completely, as, for how things are right now, seems to be like a bit of a step backwards in terms of support for vulnerability management. [15:25] mpiano, you will probably want to check the CVE OVAL instead, same URL, just switch the usn in the bz2 filename to cve. This was what we previously put on the website, but with time customers were complaining by the amount of vulnerabilities shown and instead wanted to know what vulnerabilities that we have patched they still didn't install. So we advocate for the USN OVAL on most cases. [15:27] mpiano, regarding improvements in OVAL, yes we have quite a list on things wanted there and I've been working working on it. I will take your feedback in consideration for sure and I appreciate it [15:29] mpiano, btw, which ubuntu releases are you using? [15:31] Wow, that's very interesting (I should have probably scavenged https://security-metadata.canonical.com/oval/ where that naming convention is actually explained). Thanks for letting me know I'll check that out asap. [15:34] > which ubuntu releases are you using? [15:34] basically all LTSes currently in standard support (plus a bit of Xenial which got late at being migrated) [15:35] mpiano, and you are in need of the json xenial data for cvescan right? [15:40] ebarretto, indeed, it greatly helps us draw a risk picture. But of course, if it is set for deprecation, we will do work to adapt to a different system. Being a free utility I don't feel in any position to enforce SLAs. [16:49] mpiano: re severity vs priority -- we prioritise which issues our team should work on, but that's a different thing than the severity of a given issue at a given site. Without knowing the full details of the context of how any given software is used, it's very difficult to come up with a "severity" [16:50] mpiano: attempts to do so often lead to ridiculous results like binutils issues being marked "high severity" via cvss scores; but those tools were never designed to do malware analysis, they're for building software from source code you trust. simplistic attempts to assign "severity" ratings without awareness of how the software is used isn't always helpful.. [16:57] sarnold: that's very true, it's something that I usually treat as an indication more than an absolute truth. My point was more on the fact that in the USN-indexed OVAL the severity of multiple CVEs was grouped into a single value, but this is totally solved with the other OVAL format ebarretto pointed me to. [17:03] mpiano: aha, cool cool; definitely, different people want different things from the oval. some wanted re-assurances that they ran apt-get update && apt-get upgrade correctly ;) and others want to know what issues are known but not yet fixed.. [17:09] "Thomas Sjögren: heh, that "..." <- https://ubuntu.com/engage/FIPS-on-Ubuntu-in-air-gapped-environments - have there been an update to that info? [17:09] s/info/article/ [17:10] konstruktoid[m]: good question :) [17:13] just don’t want anyone to lose face discussing air-gaps instead of having a presentation about an interesting topic