feat: verify provenance for bcr modules produced by trusted reusable workflows by loosebazooka · Pull Request #840 · slsa-framework/slsa-verifier

loosebazooka · 2025-03-11T19:52:13Z

@fweikert these are the changes I think might be needed to get this to work (it's somewhat hacky, I'm not sure I've fully covered what's needed).

@ramonpetgrave64 is this kinda what's needed?

This now adds the verify-github-attestation sub command. Use this instead of verify-artifact.

ramonpetgrave64 · 2025-03-11T21:48:50Z

@loosebazooka thanks for doing this. Yes, so far this is what's needed. Try to get a sample attestation and unit test in this file (probably in a new test function), even if it's failing.

slsa-verifier/cli/slsa-verifier/main_regression_test.go

Line 75 in b53bd94

func Test_runVerifyGHAArtifactPath(t *testing.T) {

loosebazooka · 2025-03-11T23:46:54Z

well we're currently on the dev branch of the builder, so I don't think we want to submit this in anyway. Once we finalize the builder I'll actually add tests.

alexeagle · 2025-03-17T17:57:09Z

FYI we have the first Bazel module published with attestations, and the presubmit fails since the reusable workflow isn't allow-listed here: bazelbuild/bazel-central-registry#4060

loosebazooka · 2025-03-26T15:17:19Z

working on adding tests, I've updated to configure for both the release and publish workflows

verifiers/internal/gha/verifier.go

verifiers/internal/gha/bundle.go

ramonpetgrave64 · 2025-03-28T16:48:41Z

cli/slsa-verifier/testdata/bcr/MODULE.bazel

@@ -0,0 +1,34 @@
+"Bazel dependencies"


This is the sample artifact? For folks new to bazel, can you give a quick explainer for why this file is the artifact?

Similar to a java pom.xml/go.mod or whatever. It lets bcr determine the dependency tree for a module.

ramonpetgrave64 · 2025-03-28T17:02:55Z

verifiers/internal/gha/verifier.go

+	}
+
+	return verifyEnvAndCert(signedAtt.Envelope, signedAtt.SigningCert,
+		provenanceOpts, builderOpts, defaultBCRReusableWorkflows)


I'm wondering it it makes more sense to add the new functionality in the existing VerifyArtifact()
And then depednig on the builder_id, it can decide how to extract the TriggerURI.

@laurentsimon @ianlewis

https://github.com/slsa-framework/slsa-verifier/pull/840/files#diff-2b75bff58ca87cf24fae495867d0eb3a039b63b9505b885b705ea55720777cbcR242

I'm curious what about this is specific to BCR since it looks to be just using the GitHub's attestation action. I tend to agree that this seems like this functionality could be added a bit more generically.

Yeah that was the initial pathway I took. I wanted to flag behind experimental and only allow specific builderids. The initial path was very generic, and maybe I can go back to that. I also want to only allow sigstore signed attestations

I misunderstood the generic comment, I've reworked this for now.

ramonpetgrave64 · 2025-03-28T17:03:39Z

cli/slsa-verifier/main_regression_test.go

+	bcrReleaserBuilderID := "https://github.com/bazel-contrib/.github/.github/workflows/release_ruleset.yaml"
+	bcrPublisherBuilderID := "https://github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml"
+
+	tests := []struct {


Add some negative tests for malicious attestations.

cli/slsa-verifier/main_regression_test.go

ianlewis · 2025-03-29T01:19:33Z

cli/slsa-verifier/main.go

 	}
 	c.AddCommand(version.Version())
 	c.AddCommand(verifyArtifactCmd())
+	c.AddCommand(verifyBCRModuleCmd())


It looks like the workflow is just using actions/attest-build-provenance to create an attestation.

https://github.com/bazel-contrib/.github/blob/eeb03fb7518fb0036e4bb0713134c3b6531c68ba/.github/workflows/release_ruleset.yaml#L86-L91

What about this requires specific command for bcr modules? Is it just that we are trusting a specific builder ID? Could this be a more generic command? If we want to limit verifying provenance generated by actions/attest-build-provenance to specific trusted builder IDs, could we just have an option like slsa-verifier verify-github-attestation --builder bazel-central-registry or something along those lines?

I can change this to verify-github-attestation , I'm not deep enough into slsa land to understand the consequences here. Is the builderId spoofable in any way?

oh right, builderId nees to match the SAN in the certificate

Yes. It's not spoofable because we check it against the certificate SAN (at least for sigstore which is all we support currently).

If we implemented private PKI in the future the consumer would presumably trust that the private key is only available to the build system that set the builder ID in that case.

cli/slsa-verifier/main_regression_test.go

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

There are no default builder ids for verify-github-attestation. This can perhaps be made a little more generic where any builder as long as it conforms to spec and is provided via the --builder-id flag release-workflow: https://github.com/bazel-contrib/.github/.github/workflows/release_ruleset.yaml publish-workflow: https://github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml Signed-off-by: Appu Goundan <appu@google.com>

ramonpetgrave64 · 2025-04-01T14:39:38Z

cli/slsa-verifier/main_regression_test.go

+			name:      "module.bazel using publishing builder",
+			artifact:  "MODULE.bazel",
+			source:    "github.com/aspect-build/rules_lint",
+			builderID: bcrPublisherBuilderID,
+		},
+		{
+			name:      "source archive using release builder",


For NPM, they put their build attestation and "publish" attestation together in one .jsonl file. Does it make sense for the bazel workflow(s) to do similarly?

No they are designed to execute separately unfortunately. I think we can revisit in the future. but that's how it is for now. These are also separates files. One ([release archive (my-module.tar.gz)) lives in the github repo and the others (MODULE.bazel, source.json) live in the bcr repository. Maybe the diagram in here shows that?

cli/slsa-verifier/verify/options.go

cli/slsa-verifier/verify/verify_github_attestation.go

Co-authored-by: Ramon Petgrave <32398091+ramonpetgrave64@users.noreply.github.com> Signed-off-by: Appu <appu@google.com>

ramonpetgrave64

Looks good. Just pending somethings we discussed in bazel slack about the workflows. But i think we can merge sooner than later, before an official release.

cli/slsa-verifier/verify/options.go

Signed-off-by: Appu Goundan <appu@google.com>

...instead of `slsa-verifier verify-artifact` since the latter cannot handle attestations created by the canonical GitHub action. NOTE: This change will only work once the latest slsa-verifier release contains slsa-framework/slsa-verifier#840. Progress towards bazelbuild#3829.

...instead of `slsa-verifier verify-artifact` since the latter cannot handle attestations created by the canonical GitHub action. NOTE: This change will only work once the latest slsa-verifier release contains slsa-framework/slsa-verifier#840. Progress towards #3829.

fweikert · 2025-04-07T14:38:01Z

cli/slsa-verifier/verify/verify_github_attestation.go

+
+func (c *VerifyGithubAttestationCommand) Exec(ctx context.Context, artifact string) (*utils.TrustedBuilderID, error) {
+	if !options.ExperimentalEnabled() {
+		err := errors.New("feature support is only provided in SLSA_VERIFIER_EXPERIMENTAL mode")


Is this really necessary now that it's a standalone command?

I think we should leave it for now. If we want to change the api surface or anything, I would like to do so with minimal deprecation windows.

loosebazooka · 2025-04-08T15:01:09Z

@ianlewis any other thoughts here?

fweikert · 2025-04-10T18:12:50Z

Thanks everyone! Do you have a planned date for the next release?

We need slsa-framework/slsa-verifier#840 for slsa-verifier to work, and this RC is the only version that contains it. Progress towards bazelbuild#3829

We need slsa-framework/slsa-verifier#840 for slsa-verifier to work, and this RC is the only version that contains it. Progress towards #3829

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

@alexeagle

Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets

...instead of `slsa-verifier verify-artifact` since the latter cannot handle attestations created by the canonical GitHub action. NOTE: This change will only work once the latest slsa-verifier release contains slsa-framework/slsa-verifier#840. Progress towards bazelbuild#3829.

We need slsa-framework/slsa-verifier#840 for slsa-verifier to work, and this RC is the only version that contains it. Progress towards bazelbuild#3829

Followup to #840 Resolves #849 Removes the experimental flag for verifying bazel attestations. TODO: - [ ] add example invocation for bazel #858 (review) - [ ] create a new release --------- Signed-off-by: Ramon Petgrave <32398091+ramonpetgrave64@users.noreply.github.com>

loosebazooka requested a review from a team as a code owner March 11, 2025 19:52

alexeagle mentioned this pull request Mar 17, 2025

Publish aspect_rules_lint@1.3.0 bazelbuild/bazel-central-registry#4060

Closed

loosebazooka force-pushed the addbcrverify branch from 84ba083 to 8b6d4dd Compare March 26, 2025 14:59

loosebazooka force-pushed the addbcrverify branch from 8b6d4dd to 7bc2e49 Compare March 26, 2025 15:21

alexeagle mentioned this pull request Mar 27, 2025

Publish aspect_rules_lint@1.3.1 bazelbuild/bazel-central-registry#4146

Merged

loosebazooka force-pushed the addbcrverify branch from 7bc2e49 to b62c8af Compare March 27, 2025 19:46

loosebazooka changed the title ~~WIP: POC adding bcr provenance gen to slsa-verifier~~ feat: verify provenance for bcr modules produced by trusted reusable workflows Mar 27, 2025

loosebazooka force-pushed the addbcrverify branch 3 times, most recently from 01b1958 to b73d111 Compare March 27, 2025 19:58

ramonpetgrave64 suggested changes Mar 28, 2025

View reviewed changes

ianlewis reviewed Mar 29, 2025

View reviewed changes

loosebazooka requested review from ianlewis and ramonpetgrave64 March 31, 2025 20:00

loosebazooka force-pushed the addbcrverify branch from b73d111 to c730634 Compare March 31, 2025 20:01

ramonpetgrave64 reviewed Apr 1, 2025

View reviewed changes

Update cli/slsa-verifier/verify/options.go

09bd4a7

Co-authored-by: Ramon Petgrave <32398091+ramonpetgrave64@users.noreply.github.com> Signed-off-by: Appu <appu@google.com>

mbland mentioned this pull request Apr 1, 2025

Support Bzlmod and add rules_scala to bazel-central-registry bazel-contrib/rules_scala#1482

Closed

Update cli/slsa-verifier/verify/verify_github_attestation.go

0bc8f38

Co-authored-by: Ramon Petgrave <32398091+ramonpetgrave64@users.noreply.github.com> Signed-off-by: Appu <appu@google.com>

loosebazooka requested a review from ramonpetgrave64 April 2, 2025 19:30

ramonpetgrave64 reviewed Apr 2, 2025

View reviewed changes

cli/slsa-verifier/verify/options.go Outdated Show resolved Hide resolved

loosebazooka force-pushed the addbcrverify branch from e86a602 to 8c0a2c6 Compare April 2, 2025 20:36

change provenance to attestation

8cd628d

Signed-off-by: Appu Goundan <appu@google.com>

loosebazooka force-pushed the addbcrverify branch from 8c0a2c6 to 8cd628d Compare April 2, 2025 20:38

fweikert mentioned this pull request Apr 3, 2025

Use slsa-verifier verify-github-attestation... bazelbuild/bazel-central-registry#4228

Merged

fweikert reviewed Apr 7, 2025

View reviewed changes

loosebazooka requested a review from ramonpetgrave64 April 8, 2025 15:00

loosebazooka requested a review from bobcallaway April 9, 2025 17:40

bobcallaway approved these changes Apr 10, 2025

View reviewed changes

ramonpetgrave64 approved these changes Apr 10, 2025

View reviewed changes

ramonpetgrave64 merged commit a481a19 into slsa-framework:main Apr 10, 2025
15 checks passed

fweikert mentioned this pull request Apr 10, 2025

Upgrade slsa-verifier to v2.7.1-rc.1 bazelbuild/bazel-central-registry#4298

Merged

alexeagle mentioned this pull request May 8, 2025

Something is hardcoding a requirement to use release_ruleset.yaml bazel-contrib/publish-to-bcr#262

Closed

ramonpetgrave64 mentioned this pull request Jun 12, 2025

feat: Bazel not experimental #850

Merged

2 tasks

BrewTestBot mentioned this pull request Jun 27, 2025

slsa-verifier 2.7.1 Homebrew/homebrew-core#228367

Merged

Comments

Conversation

loosebazooka commented Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ramonpetgrave64 commented Mar 11, 2025

Uh oh!

loosebazooka commented Mar 11, 2025

Uh oh!

alexeagle commented Mar 17, 2025

Uh oh!

loosebazooka commented Mar 26, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loosebazooka Mar 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ramonpetgrave64 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loosebazooka commented Apr 8, 2025

Uh oh!

Uh oh!

fweikert commented Apr 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

loosebazooka commented Mar 11, 2025 •

edited

Loading

loosebazooka Mar 29, 2025 •

edited

Loading