-
Notifications
You must be signed in to change notification settings - Fork 400
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
Feature: dry run and JSON output #684
Comments
/cc @puerco |
This seems easier than asking some other tool to invoke |
I have a PoC that wraps ko and does keyless and upload the provenance using a reusable workflow like in https://security.googleblog.com/2022/04/improving-software-supply-chain.html Note that to achieve SLSA3+, I'm more than happy to use a ko feature. If it could satisfy the "non-forgeable go command", that'd be very useful |
Can you elaborate a bit? (I'm not disagreeing, I genuinely think you know more about this than I do, I'm just trying to understand the potential attack) |
ko sees the input before invoking the go compiler. Ko then invokes the compiler using system() or fork-then-exec (please correct me if I'm wrong) which don't provide strong isolation. For example, there's a go build option called Thats the overall reasoning. Ideally we need a way to isolate the build from the provenance generation. |
One option might be to simply disallow WDYT? We can add that check pretty easily today, even before considering provenance. |
sounds good to me. These are the list of arguments we allow in our PoC https://github.com/slsa-framework/slsa-github-generator-go/blob/main/pkg/build.go#L41-L48. I think it's over constrained, but we wanted to explore tradeoff and threat model first. We may allow more arguments in the end.
Thanks. Let me know if you have more thoughts on this. |
Another example for a user to hijack their SBOM is to define Thoughts? |
At some level this isn't even a ko-specific issue, but I think we should figure this out so other tools can follow our lead. One nice thing about if we include build tags and envs in the attestation is that a consumer can inspect it to tell whether they trust it. Did it include If trusting the output of |
you're absolutely right. We're thinking of writing a blog post to highlight these problems and explain more reliable ways to do that.
+1. this is the idea behind the SLSA provenance and policies client-side.
How about a The main issue is to be sure the dry run and the actual run pull in the exact same dependencies. In go, we can vendor dependencies using
I think that'd work for Go, but I'm not sure about the container's side of things. I suppose you'd need to also vendor the base images you're downloading and let the ko command know that it should use them instead of fetching the latest in the second (compilation) run? |
My main resistance to a dry run option is that it pushes the work to compare the dry run output and the "real" output to the user, or at least some other orchestration layer invoking I'd prefer for |
the trusted builder running ko is able to report the ko version that was used. In my PoC, I use the binary from your release; I think long-term I may re-compile the project instead to be able to list its dependencies and report this in the provenance.
An allow list (instead of a dis-allow list) is more reliable in general. What are the env variable ko takes as input? Most start with Having this well documented can also help the builder's writer. In my case I'd like to only allow the env variables that ko knows it should handle, for example. |
An allowlist of go tool flags will inevitably become burdensome, I worry -- eg Go v1.1X adds
|
This issue is stale because it has been open for 90 days with no |
I'm working on generating SLSA provenance level 3 for ko using GitHub workflows - see https://security.googleblog.com/2022/04/improving-software-supply-chain.html
It's easy to generate provenance for the ko command + the env variables, however we lose some information about the go command itself. I would very much like to be able to add the go commands to the provenance.
So I think what I need is:
A dry run option, which resolves dynamically-resolved flags (ldflags) without running the compilation steps. The reason I'm asking for a dry run and not just for ko to print this info after compilation is because the arguments are not trusted and someone may pass
go build -toolexec
(execute some random command) and hijack the information. So I need this information before any user-defined arguments are "run"Other useful information that can be computed without running user input are useful, but I'm not sure what's feasible here... The SBOM for the go program could be determined post-build if the right flags are passed to the go compiler.. and I dont think you can figure which entries of the go.sum make it to the final build anyway without running the compiler. The list of base images would be useful too , but this may change between a dry run and an actual run so would not be reliable... and it can be determined post-build. Any advice/feedback welcome, though!
A way to print this in a JSON format that can be parsed by the caller, which I can then use to generate the provenance
(1) and (3) are what I'm interested in, and any recommendation for (2) are welcome :-)
The text was updated successfully, but these errors were encountered: