CFEP-XX: Make all rust packages auditable#63
CFEP-XX: Make all rust packages auditable#63xhochy wants to merge 2 commits intoconda-forge:mainfrom
Conversation
Co-authored-by: Pavel Zwerschke <pavelzw@gmail.com>
| This brings the Rust binaries on conda-forge en par with the Go binaries that have this enabled by default (see the output of `go version -m <binary>`). | ||
| Multiple distributions (Alpine, NixOS, openSUSE, Void, Chimera) already adopt `cargo-auditable` in Rust package builds (see [Adoption](https://github.com/rust-secure-code/cargo-auditable?tab=readme-ov-file#adoption)) | ||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
I'd recommend adding a Specification section where you are less specific here when it comes to implementation details, and instead focus on the goal to achieve. The concrete details about the suggested implementation can be done in a "Suggested implementation" section if needed, but not in the Specification.
For example, instead of saying "Add cargo-auditable as a hard dependency in rust-activation", you could say "Ensure cargo-auditable is installed by default in build environments that need rust". This way the specification (which is the thing we would be actually voting) wouldn't get outdated if the implementation details change over time.
|
|
||
| Implementation: [rust-activation-feedstock#79](https://github.com/conda-forge/rust-activation-feedstock/pull/79) | ||
|
|
||
| ### 2. Builds should use `$CARGO` instead of `cargo` |
There was a problem hiding this comment.
This section should be about ensuring that cargo auditable is run by default, instead of plain cargo. An environment variable is one solution, but maybe in the future we opt for injecting a cargo script with earlier precedence in PATH and then this section would not be up-to-date.
|
|
||
| The usage of the `CARGO` environment variable also ensures that Python build using `maturin` also pick up `cargo-auditable` automatically (see [maturin#495](https://github.com/PyO3/maturin/issues/2495)). | ||
|
|
||
| ### 3. Add a lint to conda-smithy for `CARGO` usage |
There was a problem hiding this comment.
This section should be about ensuring existing feedstocks migrate to the new setup. Recommended approaches can be done separately.
| cargo cyclonedx --target $CARGO_BUILD_TARGET --no-build-deps --describe binaries --format json | ||
| ``` | ||
|
|
||
| The usage of SBOMs in conda packages is dependent on a separate, soon-to-be-discussed conda enhancement proposal. |
There was a problem hiding this comment.
Please add back the "## Copyright" section as provided in the template.
| ## Future Extensions | ||
|
|
||
| In future, we may also want to ship SBOMs as part of conda packages. | ||
| We can generate them using a generic tool like [`syft`](https://github.com/anchore/syft) from the binary data or a more specific one like [`cargo-cyclonedx`](https://github.com/CycloneDX/cyclonedx-rust-cargo). | ||
|
|
||
| While `cargo-cyclonedx` is able to generate the SBOM from the `Cargo.toml` instead of the binary, keeping the dependency information in the binary allows one to check the SBOM for correctness. | ||
| The benefit of an SBOM over the binary dependency data is that it can be scanned faster. | ||
|
|
||
| An example execution of `cargo-cyclonedx` might look as follows: | ||
|
|
||
| ```bash | ||
| cargo cyclonedx --target $CARGO_BUILD_TARGET --no-build-deps --describe binaries --format json | ||
| ``` |
There was a problem hiding this comment.
This sounds more like a part of the Motivation to do this work.
3 participants
This proposal suggests integrating
cargo‑auditableinto the build process for all Rust-based feedstocks on conda‑forge.By enabling dependency‑tree embedding within compiled binaries, this integration would enhance downstream vulnerability auditing and transparency.
This CFEP is part of a longer series of CFEPs, CEP(s) and tasks we're working on at QuantCo to make the conda ecosystem compatible with various compliance "requirements", most notably the EU Cyberresiliency Act (CRA).