Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend with additional (non-rust) dependencies #99

Closed
ctron opened this issue Jan 27, 2023 · 3 comments
Closed

Extend with additional (non-rust) dependencies #99

ctron opened this issue Jan 27, 2023 · 3 comments

Comments

@ctron
Copy link

ctron commented Jan 27, 2023

Assume the following example: I create a backend application, exposing a web based interface, serving additional assets, embedded into the binary (like a JS library).

Those assets are dependencies as well, embedded into the binary. Still, they would not show up in the dependency list.

I don't think that auditable should evaluate those dependencies. However, I think it would make sense to allow a build "contribute" additional information.

Maybe just storing an SBOM?

@Shnatsel
Copy link
Member

I admit I was mostly thinking of C libraries, and assumed the use case of embedding code from other languages into the binary (e.g. a JS frontend) to be rather rare.

There is currently no unified SBOM format that works across languages and is embeddable into a binary without major issues, so I'm not sure how to even store this data short of developing our own general format and creating tooling for every language to write to it.

@ctron
Copy link
Author

ctron commented Jan 30, 2023

I think CycloneDX has an SBOM format that covers just "any" language. Same for SPDX SBOM.

I don't think that cargo auditable should be too opinionated on this, but allow for adding one ore more SBOM formats from an external source.

That could be as simple as:

enum Format { CycloneDX, SPDX, … } 
struct ExternalDependencyInformation {
 format: Format,
 content: Vec<u8>
}

@Shnatsel
Copy link
Member

Those formats are unsuitable for embedding into binaries for a variety of reasons. For example, they require including timestamps, which conflicts with reproducible builds. They're also very verbose and would add considerable overhead to the binary. See #31 for details.

cargo auditable currently only concerns itself with Cargo dependencies, with potential expansion to linked C libraries in the future. As such, I'm going to go ahead and close this issue for now.

If you're interested in this use case, I suggest starting with cargo-spdx and building out a pipeline that aggregates these SDPX files for various languages, then embedding the result into a binary using objcopy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants