cargo build: Should I keep the `target` dir after a compile for a historical audit log?

Viewed 371

I am using cargo build to build for many platforms.

Given a sha1 hash of one of the binaries I have released, I want to be able to tell exactly what input was used for the compiler (in case I need to reference it in a security audit).

I am using Docker to run cargo build, so I have hashes of each image that will be stored long term. The target dir can be many GB in size, so I do not want to be committing it to a Docker image if it is not needed.

I am not completely sure what data is contained in target.

Should I keep it, or is the Cargo.lock enough to understand what input was given to the compiler?

If a Cargo crate is deleted, is there an immutable reference I can always download (so no need to keep target which would contain the source code)?

Would running cargo build with verbose logs also be useful for a historical reference?

1 Answers

It's much cheaper in terms of storage space to store the vendored dependencies instead of storing the target folder. The sources, being essentially text files, can be further compressed to reduce the final size.

The added benefit is that you can actually use those to perform a reproducible build and even if a crate disappears upstream, you will still have it.

Just run cargo vendor and cargo will create a directory named vendor which will contain the sources of all your dependencies, including any transitive dependency. Then package those together with your app sources as a signed zip.

Related