Offline Debian builds and packaging

We've started dabbling with Rust in our organization and have enjoyed it, but we're running into a brick wall with building Debian packages. We have a build environment that has been around before SLSA compliance was an idea, but it coincidentally fits something like a "SLSA 2.5 compliance" -- somewhere between levels two and three:

Our software is built into Debian packages. These are built from the source on a build server. The dependencies are ingredients independently acquired and built as Debian packages.

In this kind of situation, a cargo build command running out to GitHub is a no-go. It looks like the --offline flag isn't taking care of this completely. The build environment sets up dependencies beforehand and runs them without network connectivity. So any attempt to reach out and touch something over the network will get slapped down.

I'm curious what I might be able to lean on to try to get cargo independent of the network. What I'm guessing is supposed to work is something like:

  1. Using rust vendor or some other command to just recursively get everything a project needs.
  2. Use the existing Debian/Rust tools to convert these to Debian packages if they aren't already in Debian.
  3. Pre-install these in the build environment. As a prototype this is fine but we'd want to vet them all officially before deploying with it for real.
  4. Plug our noses, cross our fingers, and try an offline cargo build during a dpkg-buildpackage run and hope for the best.

I was kind of hoping for some validation here before I bet burnt on it. I want to repeat we've just started dabbling with Rust and have naively leaped onto all kinds of landmines and rakes on the ground. So you might have to explain it like we're eight-year-olds.

Well, obviously you need those dependencies available locally to build the binary. Cargo's --offline flag allows to use cached version of them if network is not available. Its main use case would be like you don't have network access temporarily like during the flight but need to build it anyway.

If you need to explicitly prefetch dependencies and force to use it, cargo vendor is the go-to solution. Never miss necessary instructions this command prints to the terminal!

1 Like

Most here I think are reasonably happy with Cargo.lock for security so little effort is put into offline.

Have you read/explored how Debian does it?

1 Like

For our internal-only packages, we do the "wrong" thing and vendor into our PACKAGE.orig.tar.gz source release files. Our source relesae scripts have network access and call cargo vendor, modify ./.cargo/config to use the vendor folder, and extract author and license information from vendor/*/Cargo.toml and append it to our copyright file. After building the release, we delete the vendor folder and restore the config and copyright files. Its ugly and wrong (against Debian policies) but has been working for us so far.

There are some blog posts for the "right" way if you want eventual inclusion in Debian:

These are linked from: README.rst · master · Rust compiler tools and packages / debcargo-conf · GitLab

That seems unnecessary given the SLSA definition...

Hermetic builds guarantee that the provenance’s list of dependencies is complete.

...combined with how the Cargo.lock file works with the --locked option and the way Git hashes work.

I think I had looked at Teams/RustPackaging - Debian Wiki but it wasn't so obvious what to do with it. The Hackeriet links duelafn shared look to be expanding on what that is supposed to do. I haven't been using debcargo directly. In fact, for what I was doing, I was just packaging the generated binary and library without taking the crate. The library is using the C ABI and my binary is just a command line front end for it. I will have to just see myself what I could get out of officially using the debcargo toolchain on it.

There was also a link to a debian/rust IRC that I should take advantage of. A problem here is that my workplace had actually blocked that blog and is fussy about IRC; I think web clients are fine though. I'm actually responding from my home setup right now.

Regarding SLSA compliance: the system is very much legacy (and I believe very Debian-like) so I give that "2.5" rating kind of superficially. SLSA compliance like that wasn't really a thing when it was created so it doesn't follow those rules. Nonetheless, I have to follow the rules of the build system and try to get builds to happen without it downloading dependencies right at build time.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.