[RFC] td-shim release tagging process

[jyao1]

Hi I would like to discuss td-shim release tagging process.

[Background & requirement]
Ideally, we need to support reproducible build for td-shim.
It means: For a release image + same build environment (compiler + toolchain), we can reproduce same binary at any time and on any system.

Reference: #256

[Problem]
Currently, we do have release tag - which indicates the source code version of td-shim.
But we do not have cargo.lock - that means: Even with same source code, we might not be able to reproduce same binary, because the dependency crate might be upgraded.
That breaks the rule.

Reference: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html

Cargo.lock can be used to lock the version. However, we do want to keep using the latest crate to bug fix, or security fix.
We may consider putting Cargo.lock for the project, if we treat Td-Shim as an end project.
But if we want to treat Td-Payload as an end project, the locking td-shim is not a good idea.

Reference: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

[Possible Solution]
When we create a release for td-shim, we also create the release specific cargo.lock. That can deterministically reproduce the same release image.

[fidencio]

We must consider pinning a version of llvm, llvm-ar, and nasm as well.

One possible way to do so is providing a container image, which could be updated on every change of some parts of the project*, and also provide this container image as part of the tagging process.

Changes to track:

• Cargo.toml
• Cargo.lock
• Toolchain

This process could be fully automated via GitHub actions, as we already do something similar for Kata Containers, and users would be able to use this whenever they "recreate" the build.

[jyao1]

@fidencio , sounds great. May I assign this to you?

[fidencio]

@fidencio , sounds great. May I assign this to you?

I just did, thanks!

[dimakuv]

@jyao1 @fidencio Could you elaborate on the status of reproducible builds with TD-Shim?

If reproducible builds are implemented, does this apply to TD-Shim + payloads? In the TDX Migration TD Design Guide document, there is a section on Reproducibility, but it doesn't contain any specific information on whether it is truly supported and how to achieve it exactly (what are the steps to take).

I mention TDX Migration TD simply because IIUC it is TD-Shim + payload, similar to my case.

[jyao1]

Currently, td-shim supports reproducible build with same user id.

Currently, we use docker - see #605.