feat(checkers): Add support for llvm

[qmfrederik]

No description provided.

[terriko]

Ugh, these are all so similar. I don't think you're wrong about what you're doing, but I wonder if we can collapse them down to be auto-generated or something in a future refactoring.

[qmfrederik]

Yes, it's not pretty. The ecosystem is pretty intentional about maintaining different versions as different products (i.e. 'llvm17' is a different product than 'llvm16'), amongst others to allow multiple versions to co-exist on the same machine.

Templating is one option, subclassing may be another.

[terriko]

Looking at this again. Should we be using unknown, llvm-toolchain-* here for each CPE or do these all actually fall under the llvm, llvm category? Or is there a PURL identifier we should be looking at instead? A quick search made it seem like it should probably be the llvm, llvm, but I admit I don't know the vuln history for these components very well.

[ffontaine]

There is no CVEs linked to ("unknown", "llvm-toolchain-x") so, indeed, I would be more in favor of adding a single binary checker using ("llvm", "llvm").

[ffontaine]

There is always 3 digits in llvm version and "version" string seems to be mandatory so I would suggest to replace:

        r"LLVM (?:version )?([0-9]+\.[0-9]+(\.[0-9]+)?)",
        r"/llvm-[a-z]+/([0-9]+\.[0-9]+(\.[0-9]+)?)",

by

        r"LLVM version ([0-9]+\.[0-9]+\.[0-9]+)",
        r"/llvm-[a-z]+/([0-9]+\.[0-9]+\.[0-9]+)",

[qmfrederik]

Thanks @ffontaine . I seem to remember having seen an instance where the word version was not part of the version string, but I can't find that example. So I simplified the PR accordingly.

[ffontaine]

Hi @qmfrederik, when I double-checked, one of your previous iteration, I found out that you added llvm in other_products of go-1.13.13-r0.apk.tar.gzbecause /usr/lib/go/src/runtime/race/race_freebsd_amd64.syso contains
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)

If you think that llvm was indeed really used to compile race_freebsd_amd64.syso, please revert the change that I asked concerning the version word. I have no strong opinion on my side.

[qmfrederik]

@ffontaine I think we can leave this as is for now -- I assume it will detect clang, which is probably good enough a proxy for LLVM at the moment.

@terriko If you agree, then this PR is ready (the spelling check appears to be a flake)

[terriko]

Okay, I think I agree that this is ready to go (sorry I missed that it's been ready for a while because I was doing hackathon stuff!) I'm going to update the branch and re-run tests just in case, but assuming they pass I intend to come back and merge this.

[ffontaine]

All tests successful, I could merge it however @terriko what is the merge rule for cve-bin-tool? Is it fine to "squash and merge"?

[terriko]

@ffontaine Yes, I typically squash and merge (often editing the long commit message down to something reasonable if there's been a lot of churn). The times when I haven't done that are mostly mistakes due to using a different browser and not realizing which was the default selection.

Anyhow, I'll get this merged now, thank you @qmfrederik for your patience!