Coverity Scan has been down more than up for the last 6 months or so -- and hasn't had any significant scanner updates in years. I think at this point we just have to assume that #Coverity scan isn't coming back. It's a sad end to a once-useful service.

#enshittification #privateequity

Does anyone know what is happening at #coverity? The 'open source' dashboard is down since a while. Did they went belly up?

https://scan.coverity.com/dashboard

BSDCan https://www.bsdcan.org/2026/ Talk Friday 2026-06-19: 09:45 - 10:35 DMS 1110
Using Coverity Scan for static code analysis in NetBSD
Emmanuel Nyarko
https://www.bsdcan.org/2026/timetable/timetable-Using-Coverity-Scan.html
To register https://www.bsdcan.org/2026/registration.html @bsdcan #netbsd #coverity #deveopment
BSDCan - BSDCan

BSDCan is a technical BSD conference held in Ottawa, Ontario, Canada.

BSDCan

It was 133rd in the queue today, so I just killed it. We don't do #Coverity testing anymore.

It's always felt wrong using a proprietary, closed-source tool. With its terrible UI, tie-ins to GitHub, CAPTCHAs, non-existent support (emailed a question in August - no reply), increasing delays for scans (two days and I'm still 133rd in the queue?) I'm getting off.

Our FOSS tools are excellent and getting better all the time. I'm done wasting time with a black-box that mostly gives false positives.

One static analysis tool tells me to use `lstat` and `fstat` to avoid (or at least detect) malicious replacement of a file that I `open`. Then, after doing this, my other static analysis tool complains that I’ve introduced a TOCTOU (time-of-use, time-of-check) between `lstat` and `open`.

Sure, but I’m going to detect that. Real issue I have with all of this is that there’s still a window (which I estimate to be the about the same size in both versions of this program) between creating this pseudoterminal file and the next interaction I have with it (be that pulling file stats with `lstat` or `open`ing it).
#SemGrep #Coverity #StaticAnalysis #Programming #C

Aaand… now #wile #scheme #compiler is fully #coverity-clean 😎 After the last round of cleanups, there were three types of defect remaining: uninitialized origin fields in lisp-val structs, which were harmless but I now set them all to a safe default value; structurally dead code, which is stuff my dead-code eliminator doesn’t catch yet; and uses of drand48, which got flagged as cryptographically insecure. I marked the last two classes as false positive/intentional, and now there’s nothing left.

I’m pleased to announce release 1.0.4 of #wile #scheme #compiler. There are *no new features*, just a fair number of #coverity cleanups - thank you Coverity/Synopsys for allowing open-source projects to access this!

It’s available at https://github.com/uhollerbach/wile as usual.

GitHub - uhollerbach/wile: A small simple scheme compiler

A small simple scheme compiler. Contribute to uhollerbach/wile development by creating an account on GitHub.

GitHub
Very cool! I redid the #coverity scan of #wile #scheme #compiler, this time with garbage collection enabled, and ~500 defects vanished 😎 I had also fixed a number of real issues, so now I’m down to a small handful of isolated issues plus a larger number which is all one problem, and not too serious: I have an ‘origin’ field in lisp-val structs, to track where they come from, and I haven’t fully initialized that yet everywhere. That basically only goes into error messages. Not a huge problem.
Well. I signed up for #coverity scanning for #wile #scheme #compiler a while ago, they offer free scanning to open source projects, and I just submitted my first cov-build for scanning. Very curious to see what it will report.

Finally, a #Coverity analysis completed!

I submitted one earlier today - it deleted it from the queue, but apparently later actually analyzed it and it passed. Have been trying since Monday. Perhaps the server upgrades have finally settled.