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

Attestation output file format (base64 or no?) #129

Open
ianlewis opened this issue May 30, 2022 · 6 comments
Open

Attestation output file format (base64 or no?) #129

ianlewis opened this issue May 30, 2022 · 6 comments
Labels
area:generic Issue with the generic generator area:go Issue related to the Go ecosystem type:discussion A point of discussion

Comments

@ianlewis
Copy link
Member

@laurentsimon The Go builder outputs json provenance as base64 encoded. The generic provenance-only builder just outputs json without encoding. I'd like to be consistent, but base64 encoding didn't seem to me to provide any particular benefit. Any reason that json output for the Go builder encodes the data in base64?

encoded := base64.StdEncoding.EncodeToString(jsonData)
if err != nil {
return "", fmt.Errorf("base64.StdEncoding.EncodeString: %w", err)
}

@ianlewis ianlewis added area:go Issue related to the Go ecosystem area:generic Issue with the generic generator type:discussion A point of discussion labels May 30, 2022
@ianlewis ianlewis added this to the v1 milestone May 30, 2022
@laurentsimon
Copy link
Collaborator

@ianlewis
Copy link
Member Author

Hmm, I got confused as to the Go builder's output because e2e-verify.sh seems to base64 decode the entire file.

# Provenance content verification.
ATTESTATION=$(cat "$PROVENANCE" | base64 -d)

This seems to be different from the scripts in example-package which extracts the payload. I'm not sure how the e2e pre-submits work for the Go builder if that's the case. 😕
https://github.com/slsa-framework/example-package/blob/main/.github/workflows/scripts/e2e-verify.sh#L134-L135

@ianlewis
Copy link
Member Author

It's part of the DSSE format https://github.com/secure-systems-lab/go-securesystemslib/tree/main/dsse Here's an example of the final results https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/go/testdata/binary-linux-amd64.intoto.jsonl

I also thought that sigstore's dsse library did the base64 encoding for us so we shouldn't have to do it ourselves.

wrappedSigner := dsse.WrapSigner(k, intoto.PayloadType)
signedAtt, err := wrappedSigner.SignMessage(bytes.NewReader(attBytes))
if err != nil {
return nil, fmt.Errorf("signing message: %v", err)
}

@laurentsimon
Copy link
Collaborator

laurentsimon commented May 31, 2022

Hmm, I got confused as to the Go builder's output because e2e-verify.sh seems to base64 decode the entire file.

# Provenance content verification.
ATTESTATION=$(cat "$PROVENANCE" | base64 -d)

This seems to be different from the scripts in example-package which extracts the payload. I'm not sure how the e2e pre-submits work for the Go builder if that's the case. 😕 https://github.com/slsa-framework/example-package/blob/main/.github/workflows/scripts/e2e-verify.sh#L134-L135

sorry, I get the confusion. For pre-submits, we omit the signature (no OIDC write access) but still base64-encode to be consistent with DSSE https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/go/pkg/provenance.go#L145

In example-package, the full DSSE is used, so we extract the payload from the DSSE (base64--encoding is done by sigstore API).

I have kept the base64-encoding on pre-submit because it's like an opaque string to pass around VMs (and it's consistent with DSSE), but besides that it has not particular benefits.

@ianlewis
Copy link
Member Author

ianlewis commented Jun 3, 2022

Ok, I'll just get something working for my presubmit and we'll think about how we might clean this up moving forward. Maybe just adding some comments to clarify things would help for now.

@ianlewis ianlewis removed this from the v1 milestone Jun 3, 2022
@ianlewis
Copy link
Member Author

ianlewis commented Jun 3, 2022

Removed from v1 as it's not critical to solve right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:generic Issue with the generic generator area:go Issue related to the Go ecosystem type:discussion A point of discussion
Projects
None yet
Development

No branches or pull requests

2 participants