cargo-auditable VS svntogit-community

Further we use cargo-auditable and cargo-audit as part of both our pipeline and regular scanning of all deployed services. This makes our InfoSec and Legal super happy since it means they can also monitor compliance with licenses and patch/update timings.

This exists, see cargo auditable.

The Rust community seems to have settled on a perfectly reasonable way to address bit-rot in statically linked binaries. https://github.com/rust-secure-code/cargo-auditable

Would you be open to integrating cargo auditable into this pipeline in some form? It seems like a great match.

> and static compilation probably just hides the problem unless security scanners these days can identify statically compiled vulnerable versions of libraries

Some scanners like trivy [1] can scan statically compiled binaries, provided they include dependency version information (I think go does this on its own, for rust there's [2], not sure about other languages).

It also looks into your containers.

The problem is what to do when it finds a vulnerability. In a fat app with dynamic linking you could exchange the offending library, check that this doesn't break anything for your use case, and be on your way. But with static linking you need to compile a new version, or get whoever can build it to compile a new version. Which seems to be a major drawback of discouraging fat apps.

1: https://github.com/aquasecurity/trivy

2: https://github.com/rust-secure-code/cargo-auditable

I have investigated a bunch of standardized formats - SPDX, CycloneDX, etc. All of them are unsuitable for a variety of reasons, chief of which are being way too verbose and including timestamps, which would break reproducible builds.

The fix for interoperability with cargo auditable has also shipped in the latest release of sccache. You can use the released sccache now instead of building it from git!

I've been working to bring vulnerability scanning to Rust binaries by creating cargo auditable, which embeds the list of dependencies and their versions into the compiled binary. This lets you audit the binary you actually run, instead of the Cargo.lock file in some repo somewhere.

cargo auditable solves this problem by embedding the list of dependencies and their versions into the binaries. But until it becomes part of Cargo and gets enabled by default, static linking will remain problematic.

The author of the AUR package, removed it from the community repo and moved it to the AUR. And now it has another maintainer in the AUR.

The original maintainer still maintains 2185 packages [2].

Can't find an explanation why though.

[0]: https://github.com/archlinux/svntogit-community/commit/2b5ec...

[1]: https://aur.archlinux.org/cgit/aur.git/commit/?h=units&id=e6...

[2]: https://archlinux.org/packages/?packager=arojas

In /usr/bin/ there is no cargo binary after new update. If I try call it in shell it says bash: cargo: command not found. I tried to understand git commit message - symlink was changed and rust-analyzer is deleted. So I need to add some environment export to my shell and install rust analyzer from now?

The package was updated 18 hours ago (https://github.com/archlinux/svntogit-community/commit/a389cb3538aa3c73e2ca75227c151bbcdaf0bfa2) please check your mirrors!

Guess there is no easy way, well here is a command that will generate a nice list: curl -L https://github.com/archlinux/svntogit-community/raw/packages/nerd-fonts/trunk/PKGBUILD 2> /dev/null | tr -d '\n' | grep -oP '(?<=pkgname=\().*?(?=\))' | sed -r 's/\s+/ /g'

Here's the PKGBUILD link: https://github.com/archlinux/svntogit-community/blob/packages/signal-desktop/trunk/PKGBUILD

About a week ago I began encountering some little bugs with a few application's icons in the system tray. I use Arch with GNOME Wayland and Papirus icons, and my only extension is gnome-shell-extension-appindicator. I believe it started after this update: gnome-shell-extension-appindicator (specific commit in question)