Provide git tags for binary crate releases

[jcgruenhage]

I'm packaging cargo-auditable and rust-audit-info for Void Linux, and for that it'd be very helpful to have git tags available for at least the binary crates. As far as I can tell, the tags already present are for cargo-auditable itself, so this is mostly about providing tags for rust-audit-info as well. An approach that works well for multiple projects with distinct versioning is using some tag prefix containing the crate name, like this for example: https://gitlab.com/openpgp-card/openpgp-card/-/issues/32#note_958397205

[Shnatsel]

Thank you for packaging cargo auditable! I see cargo audit already uses this tagging scheme, so I'll apply it here as well.

Could you point me to some documentation on how tags are used in packaging? I'd like to understand the use case better so that I don't break anything accidentally.

Also, I understand the dependency versions are not tracked? So if I ship some important fix in a library crate, I should also cut a new release of the binary crates so that it gets into distros - is that correct?

[Shnatsel]

Also, would keeping the current tagging scheme for cargo auditable and using the prefix only for rust-audit-info work, or having prefixes for both is preferred?

[jcgruenhage]

Thank you for packaging cargo auditable! I see cargo audit already uses this tagging scheme, so I'll apply it here as well.

You're welcome! I'm very happy to see stuff like cargo auditable, and I'd like to integrate it into Void enough that the binaries shipped by Void are auditable as well, because unlike distros like Fedora, we don't have a separate package for each rust crate, meaning that we don't replicate the library dependencies into our package manager. Without tooling like cargo auditable, this information is hard to come by, because the Cargo.lock file isn't shipped either. The information isn't lost, but it's not readily available.

Could you point me to some documentation on how tags are used in packaging? I'd like to understand the use case better so that I don't break anything accidentally.

https://github.com/void-linux/void-packages/pull/40265/files#diff-ca87b626d0d2e8ee6ae7022cff8cbbd40f794434d990f306ceab1ae3f1812f3fR11 would be an example here, https://github.com/void-linux/void-packages/blob/master/srcpkgs/sequoia-sq/template#L15 another one. It's not complicated, we basically just pull in the archive and put in the version number in the right place.

Also, I understand the dependency versions are not tracked? So if I ship some important fix in a library crate, I should also cut a new release of the binary crates so that it gets into distros - is that correct?

That would be the case either way, as for binary crates there's usually a Cargo.lock present. Until the Cargo.lock file is updated, rebuilding the application doesn't pull in newer library versions, so a new version with an updated Cargo.lock would then get picked up by distros.

Also, would keeping the current tagging scheme for cargo auditable and using the prefix only for rust-audit-info work, or having prefixes for both is preferred?

Doesn't matter much, either way works for me.

[Shnatsel]

Alright, I'll use v{version} tags for cargo auditable and rust-audit-info/v{version} tags for rust-audit-info.

I've just published a new release of rust-audit-info too. It's a no-op in terms of functionality but migrates to auditable-info v0.6, making it easier to package in distros that do convert all dependencies into their own packages. It is already tagged.

I'm very happy to see stuff like cargo auditable, and I'd like to integrate it into Void enough that the binaries shipped by Void are auditable as well

I'd be very happy to see that happen! Please let me know if you need any changes in the tools to make that happen.

Are you looking to use cargo audit or some other tool for the actual scanning? I'm actually about to ship a new release of cargo audit with significant improvements to binary scanning.

Come chat with us on Zulip if you want to discuss this further!

[Shnatsel]

cargo audit v0.17.3 with improved binary scanning has shipped. Here's the changelog:

https://github.com/rustsec/rustsec/blob/7164fc77d0226529cde744c51dd67030029c4881/cargo-audit/CHANGELOG.md

[jcgruenhage]

I'm very happy to see stuff like cargo auditable, and I'd like to integrate it into Void enough that the binaries shipped by Void are auditable as well

I'd be very happy to see that happen! Please let me know if you need any changes in the tools to make that happen.

I don't think we'll need any changes for that, no. In fact, most of the work there is already done: void-linux/void-packages#40272. The changes are in good shape, and so far the feedback has been positive, so I'm fairly hopeful that this will be merged soon, meaning we'll any newly built packages from then on will include the dependency tables :)

Are you looking to use cargo audit or some other tool for the actual scanning? I'm actually about to ship a new release of cargo audit with significant improvements to binary scanning.

The cargo audit version shipped by Void doesn't include the binary-scanning feature right now, but it might make sense to ship that as well. For now, the focus is enabling users to get a SBOM out of the binaries later on, what we or the users do with the SBOM later is not quite as clear yet. For me personally I used syft today to find where I have openssl3 in containers, and realised I wouldn't have such an easy time to figure out what's affected when I'd have to do the same with statically linked rust binaries. syft also works with the dependency table included by cargo-auditable, so I'm happy with that for now.

Come chat with us on Zulip if you want to discuss this further!

I'm mostly on matrix, never really got warm with zulip, so I'm unlikely to come around to just hang out, but I'll keep it in mind for when I have concrete questions that don't really fit into issues/PRs. Thanks!

[Shnatsel]

I see the PR for building Rust packages in Void Linux has been merged. I'm curious, when will it actually reach users? Like, is it going to apply to the next stable release, or is reaching users already through a rolling release? And are only newly built packages getting metadata embedded into them, or will there be a rebuild?

[jcgruenhage]

It has already started reaching users, through a rolling release. For now, it only affects newly built packages, but I think we'll do a rebuild at some point, for the packages that don't get updated that often. I just checked: fd, which had it's update merged yesterday, was already distributed with the metadata embedded.

[Shnatsel]

Do let me know if you run a rebuild - that'd be quite a milestone, and I'd be happy to announce it more widely!

[jcgruenhage]

One small sidenote: Even with a rebuild, this only catches close to 90% of our rust packages. Places where cargo is not used by setting the build_style to cargo, but invoked in a Makefile or a meson build or something like that (which includes for example a few Gnome apps, but also our rust and cargo packages), those binaries don't contain the embedded metadata yet. Either way, when a rebuild happens, I'll be sure to let you know!