Support unsigned command verification into the tool

[zsims]

This closes #14 by allowing a list of commands to be specified that can remain unsigned. This ensures plugins are still verified, and/or the step is still verified if a step signature is found.

I'll look at a "command eval" style approach in a future PR -- e.g. any script in the repository may be executed by default.

[zsims]

I'm wondering how configurable this needs to be @lox... I'm thinking this could instead be some hard coded rules that are:

1. Allow any local/repository script (no command eval style); and/or
2. Allow buildkite-signed-pipeline upload <a local file here>

Keen for thoughts, as the above is really the behaviour most people would want (I imagine)

[zsims]

Note that the rules get slightly complex if plugins are referenced, but the kingpin command parsing could be used to disambiguate buildkite-signed-pipeline upload, e.g.

if strings.HasPrefix(command, "buildkite-signed-pipeline upload") {
  // do kingpin parsing of `command`
  // work out what the `file` is (if any)
  // check to make sure `file` is a file in the repository
}

[zsims]

I'll look at this as part of #16 -- as this PR closes the possibility of plugins to be injected into "allowed commands"

[lox]

I reckon it might be a good idea to write up in the README "attack scenarios", e.g what potential threats we are aiming to solve and scenarios and how buildkite-signed-pipeline defends against them. Otherwise it's easy to forget edge cases when we are adding new features. If I get a chance I'll make a start!

[zsims]

Good idea, will help shape this :-)

[lox]

Typo? pstep

[zsims]

Good pickup! Indeed

[lox]

This is looking really good, nice one @zsims

[zsims]

After writing up the attack scenarios (great suggestion, many thanks 😁) I'm not convinced this level of flexibility is needed as from what I've seen consumers want to be able to:

1. Call builkite-signed-pipeline with any arguments; or
2. Run a script in their repository

Do you think it's worth addressing those first? This PR won't let you call buildkite-signed-pipeline upload mypipeline.yml unless you explicitly allow it -- which is hard to do given it's pipeline specific where this tool runs on agents

[lox]

After some thought, I completely agree. I reckon we should keep it simple and not introduce this!

[zsims]

Awesome, will look at a simple PR that let's through unsigned buildkite-signed-pipeline upload invocations.