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

[Bug]: command-run attestor type complains about missing command #373

Open
Strakeln opened this issue Jan 29, 2024 · 2 comments
Open

[Bug]: command-run attestor type complains about missing command #373

Strakeln opened this issue Jan 29, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@Strakeln
Copy link

What steps did you take and what happened:

Attempted to generate a command-run attestation, specified the following:

witness run -a command-run -s test -k key.pem -o output.json -- echo "hello" > test.txt

outputs the following:

INFO Starting material attestor...
INFO Starting command-run attestor...
INFO Starting command-run attestor...
ERROR Error running command-run attestor: invalid value for option Cmd: CommandRun attestation requires a command to run
ERROR failed to run attestors: invalid value for option Cmd: CommandRun attestation requires a command to run

What did you expect to happen:

Expected an output attestation with material, product, and command-run attestors.

Anything else you would like to add:

I was able to successfully generate the command-run attestation I was looking for by running the same command with a blank attestor type string:

witness run -a "" -s test -k key.pem -o output.json -- echo "hello" > test.txt

INFO Starting material attestor...
INFO Starting command-run attestor...
INFO Starting product attestor...

Environment:

  • Witness version: 0.1.14 and 0.2.0
  • Architecture: Linux amd64
  • Attestors used: material, product, command-run
@Strakeln Strakeln added the bug Something isn't working label Jan 29, 2024
@ChaosInTheCRD
Copy link
Collaborator

Hi @Strakeln - Sorry for taking time to respond here, we'll try to get back faster in the future.

This is something that we need to make clear in both the documentation and the CLI UX. The command-run attestor is what wraps and generates an attestation from the arguments you supply as [cmd] in witness run [cmd] [flags]. Said arguments are the only way we expose this attestor (it wouldn't make sense to allow users to supply the command-run inputs with a flag or some other input method), and this attestor will run every time said arguments are supplied. Of course if you know of a reason why we should let people invoke the command-run attestor another way, please let us know in the issue.

You can make the command-run attestor not run if you don't specify any arguments:

witness run -s test -k key.pem -o output.json

I think the plan is for the command-run attestor to not be 'presented' to the user as an attestor type given its status as a primitive function of the Witness CLI, and instead an attestation type that will be outputted from the use of Witness. Again if you think this isn't the right direction please let us know 😄.

@Strakeln
Copy link
Author

Howdy @ChaosInTheCRD - your response time is just fine!

Your explanation makes sense. Given that, my suggestion would be to consider one of the following:

  1. Documenting the ability to clear the default attestors by specifying -a "" (apologies if this is documented already somewhere that I haven't noticed yet), or
  2. Enabling the user to specify command-run (to essentially accomplish the same thing - clearing out the default attestors)

My reasoning here relates to the use case of someone only wanting to generate a command-run attestation (in addition to the product and material attestations, of course). Currently, if no -a option is specified, it will run git and environment attestors. The git attestor will fail if the user is not in a git repository, and the environment attestor is currently somewhat risky due to the things it can expose. This is what led me down the path of trying to specify the command-run attestor, eventually landing on specifying the empty string based on a colleague's discovery of that feature.

Thank you for your response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants