Support cargo-auditable

[NobodyXu]

Checklist

• I've looked through the issues and pull requests for similar request
• This feature could be solved with a custom docker image (optional)

Describe your request

I would like to use cargo-auditable along with cross to cross build a binary that is auditable.

I've already posted this on cargo-auditable rust-secure-code/cargo-auditable#95 but @Shnatsel suggests me to file an issue here:

Hmm. I think the best way forward is to file an issue on the cross issue tracker about potentially supporting cargo auditable. Basically a call to cargo auditable sets RUSTC_WORKSPACE_WRAPPER to itself, and saves the arguments it received into an environment variable so that the wrapper then recovers it. That's basically it as far as integration is concerned.

Describe why this would be a good inclusion for cross

It will make it possible to use cross with cargo-auditable.

Additionally any program that uses RUSTC_WORKSPACE_WRAPPER can interoperate with cross.

[Shnatsel]

cargo auditable sets not just RUSTC_WORKSPACE_WRAPPER but also other variables that need to be passed on.

I'm not at all familiar with Docker, but if cross builds binaries in Docker, I believe it could be solved with a custom Docker image? You'd just have to configure the Docker image to use cargo auditable as a drop-in replacement for Cargo.

[Shnatsel]

Alternatively you could use the pre-build hook to install cargo auditable and set it up as a drop-in replacement for Cargo in all images, without having to build a custom image for every target.

[NobodyXu]

I'm not at all familiar with Docker, but if cross builds binaries in Docker, I believe it could be solved with a custom Docker image? You'd just have to configure the Docker image to use cargo auditable as a drop-in replacement for Cargo.

Yep, I think it's possible.

Alternatively you could use the pre-build hook to install cargo auditable and set it up as a drop-in replacement for Cargo in all images, without having to build a custom image for every target.

I'd do that if cargo-auditable provides pre-built binaries.
It's hard to cache cargo-auditable that way.

[Shnatsel]

We don't provide prebuilt binaries right now - perhaps that's something we ought to use cross for!

But you can easily create your own binary cache with cargo binstall.

[NobodyXu]

But you can easily create your own binary cache with cargo binstall.

Well, since cargo-binstall also supports quick install and quick install will build cargo-auditable if it is requested for many times, that will work though the first several builds would still be built-from-source.

P.S. I actually is one of the maintainers of cargo-binstall and is considering using cargo-auditable in it, but the CI already takes quite long so a bit hesitant to do it.

I wish cross supports pre-built hook for release only since we can absolutely tolerate the release CI to be much longer.

[Shnatsel]

I believe that's what custom Docker images are for? You can build the image once, then cache it?

Alternatively we could have Github Actions build cargo auditable binaries and publish them to Github Releases for the most common platforms, so that there always would be prebuilt binaries to download. I'm currently occupied with other things but I'm happy to accept a PR. For cargo auditable this code is twice the fun because we first need to build the latest cargo auditable and then build the release artifact with it.

[NobodyXu]

I believe that's what custom Docker images are for? You can build the image once, then cache it?

Yeah, that's a reasonable solution.

Alternatively we could have Github Actions build cargo auditable binaries and publish them to Github Releases for the most common platforms, so that there always would be prebuilt binaries to download.

I would definitely love that.

I'm currently occupied with other things but I'm happy to accept a PR.

I would do so if I have time.
I also wish there's some kind of template for this cargo-bins/cargo-binstall#309

For cargo auditable this code is twice the fun because we first need to build the latest cargo auditable and then build the release artifact with it.

Oh bootstraping, but that can be cached right?
So not a big offender in CI runtime.

[Shnatsel]

Mostly, yes. cargo auditable slots nicely into Cargo's caching system, and rebuilds very little code when you switch from cargo build to cargo auditable build on the same project.

Regardless, we need to bootstrap only when we cut a new release, so I'm OK with CI times for those particular jobs being high.

[Emilgardis]

I think this is a duplicate of #716, but we did not consider workspace wrappers in the current implementation, right @Alexhuszagh ?

[Shnatsel]

Right now as long as you copy over the cargo-auditable binary into the container and invoke it appropriately, it should work. It is only a single binary with no external dependencies other than libc.

The only potential issue I can see is the container's glibc being too old, which applies to all subcommands, and you could work around that by building with statically linked musl.

[Shnatsel]

I see this has been closed as completed, but I can't find any recent pull requests that seem relevant. #716 is also still open.

Could you point me to the changes made to support it, and how can I make use of cargo auditable with cross?

[NobodyXu]

@Shnatsel I closed this because I switched to using cargo-zigbuild and it has been stale for quite some time, so I thought it's already solved.

[NobodyXu]

Sorry, I have reopened it.

[Shnatsel]

A custom image or a pre-build hook can be used as a solutions. I suppose this can be closed in favor of #716 that tracks support for all subcommands.

[Emilgardis]

yes lets move it to #716

[Emilgardis]

supposedly you can mark issues as duplicate, lets try

Duplicate of #716

edit: nope :)

[NobodyXu]

I believe that's what custom Docker images are for? You can build the image once, then cache it?

Alternatively we could have Github Actions build cargo auditable binaries and publish them to Github Releases for the most common platforms, so that there always would be prebuilt binaries to download. I'm currently occupied with other things but I'm happy to accept a PR. For cargo auditable this code is twice the fun because we first need to build the latest cargo auditable and then build the release artifact with it.

P.S. cargo-quickinstall has been using cargo-audit to build pre-build artifacts since then and it can build cargo-audit with cargo-audit.