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

Enhance runlib to allow users to add arbitrary data to environment / record environment from the CLI #307

Open
adityasaky opened this issue Sep 19, 2019 · 5 comments

Comments

@adityasaky
Copy link
Member

Description of issue or feature request: The in-toto spec doesn't mandate a specific format for the environment field in link metadata. It does recommend that the field must contain variables for environment variables, filesystem for a list of relevant filepaths or hashes, and workdir for the present working directory.

The in-toto-run and in-toto-record CLI commands don't currently have an option to record the environment / any other information the user wants to. However, runlib does include a record_environment for in_toto_run and in_toto_record which records the present working directory.

Current behavior: Doesn't exist.

Expected behavior: Add options that allow users to record environment from the CLI as well as store any other information.

@chunteck
Copy link

Hi,

I'm exploring using in-toto to generate provenance/metadata for my CI/CD pipeline, and I ran into an issue whereby I need to capture environment data (e.g instance id, job id) into the link metadata, so that I can verify that the artifacts generated were indeed built by specific instances/servers.

I came across this issue and was wondering if there are any future plans to allow us to specify environmental data that in-toto-run command can capture and save into the link metadata files.

Otherwise, are there any suggestions as to how I can include information about the build environment into the link metadata files?

@adityasaky
Copy link
Member Author

Hi @chunteck, some of the thinking behind env has been captured in the new in-toto / SLSA provenance specification. Have you checked that out yet? It's got a builder.id field for example that should address your need.

https://slsa.dev/provenance/v0.2

@chunteck
Copy link

Hi @adityasaky, if I use the new SLSA provenance specification, I would need to write a script to generate the provenance myself right? Does in-toto support generating the new specification, or have future plans to support the new specification? Right now it seems that only the old link metadata specification is generated when using in-toto-run

@adityasaky
Copy link
Member Author

The SLSA provenance model is defined in in-toto-golang (https://github.com/in-toto/in-toto-golang/blob/master/in_toto/slsa_provenance/v0.2/provenance.go) but there isn't a workflow there like in-toto-run that generates it.

@chunteck
Copy link

noted, thanks!

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