Re: Scanning the entire Ports tree for Rust vulns

On 2026-05-09 23:25, Alan Somers wrote:
> TLDR; It's possible to preemptively scan the whole ports tree for Rust
> crates with known vulnerabilities, without building anything
>
> Background: Every Rust project lists its dependencies in a
> standardized format (Cargo.lock).  A widely used tool (cargo-audit)
> can read that format to look for any dependencies with known security
> vulnerabilities registered in a public database[^1].
>
> Our ports tree doesn't store the Cargo.lock files; those come from the
> projects themselves.  However, the majority of our Rust ports do store
> their dependencies in a different standardized format: Makefile.crates
> .  And it turns out that this format actually contains all of the
> information that cargo-audit needs.  An awk script is sufficient to
> turn a Makefile.crates file into a partial Cargo.lock file that's good
> enough for cargo-audit.
>
> Doing that turns up about 185 unique vulnerabilities and 3000 known
> port-vulnerability pairs.  Many of them are minor, more like lints
> than vulnerabilities.  But some are serious.  For example, we have 38
> ports vulnerable to one particular remote DoS bug [^2].
>
> Fixing all of the alerts would obviously be a ton of work.  The first
> step would be filtering it to discard many of the less-serious alerts.
> So I don't know if it would really be worthwhile.  I'm not planning to
> do it myself, but I thought I would share my work here in case anybody
> else is interested.
>
> Here is the basic script:
>
> #! /bin/sh
>
> for f in `find . -name Makefile.crates`; do
>      awk -F '([\t ]|-)' '
> BEGIN {
>      print("version = 4");
> }
> $(NF-1) ~ /[0-9]+\.[0-9]+\.[0-9]+/ {
>      print("[[package]]");
>      print("name = \"" $(NF-2) "\"");
>      print("version = \"" $(NF-1) "\"");
> }'    $f > /tmp/Cargo.lock
>      cargo-audit audit -f /tmp/Cargo.lock
> done
>
> [^1]: https://rustsec.org/
> [^2]: https://rustsec.org/advisories/RUSTSEC-2024-0336.html

As much as I would like to say that's great I think we can more or less 
conclude that security in ports tree as a whole is of very low priority 
(you're beating a dead horse). It takes weeks/months to land fixes for 
high profile libraries and/or applications. We don't even try to 
deprecate unmaintained software, even if it has known vulns. Some 
committers don't care because it "hurts"/"disables" one or many of their 
ports. There's no evaluation of adding new software, "everything" gets 
added, being very niche, dead for years or origin might call for extra 
evaluation there are no concerns to mention a few topics. bofh@ made a 
talk about this some other things several months ago and so far the 
response has been cricket noise.

Best regards,
Daniel