BYOB: Integrating JReleaser

[aalmiray]

Hello everyone!

A few days ago I had conversation with @laurentsimon and @loosebazooka about options to create a custom SLSA builder for JReleaser. The first hurdle was to figure out how to get all artifacts to be built by the Callback GH Action. We managed to clear that out by leveraging JReleaser's extension hooks.

The following configuration file may be used to:

• invoke maven to build and deploy to a local staged repository
• assemble a Zip distribution
• deploy staged artifacts to Maven Central
• create a GitHub release and upload the Zip as asset

hooks:
  command:
    before:
      - cmd: './mvnw -Ppublication'
        filter:
          includes: ['assemble']

project:
  name: helloworld
  description: HelloWorld in Java
  longDescription: HelloWorld in Java
  links:
    homepage: https://github.com/jreleaser/helloworld-java-bin
  authors:
    - Andres Almiray
  license: APACHE-2.0
  inceptionYear: 2023
  stereotype: cli
  java:
    version: 11
    groupId: org.jreleaser.examples
    artifactId: helloworld
    mainClass: org.jreleaser.examples.HelloWorld

release:
  github:
    overwrite: true
    changelog:
      formatted: ALWAYS
      preset: conventional-commits
      contributors:
        format: '- {{contributorName}}{{#contributorUsernameAsLink}} ({{.}}){{/contributorUsernameAsLink}}'

assemble:
  javaArchive:
    helloworld:
      active: ALWAYS
      formats: [ ZIP ]
      fileSets:
        - input: '.'
          includes: [ 'LICENSE' ]
      mainJar:
        path: target/{{distributionName}}-{{projectVersion}}.jar

signing:
  active: ALWAYS
  armored: true

deploy:
  maven:
    nexus2:
      maven-central:
        active: ALWAYS
        url: https://s01.oss.sonatype.org/service/local
        snapshotUrl: https://s01.oss.sonatype.org/content/repositories/snapshots/
        closeRepository: true
        releaseRepository: true
        stagingRepositories:
          - target/staging-deploy

The following commands are required for build, assembly, and release

$ jreleaser assemble && jreleaser full-release

This creates the following staged artifacts for deployment to Maven Central

target/staging-deploy/
└── org
    └── jreleaser
        └── examples
            └── helloworld
                ├── 1.0.0
                │   ├── helloworld-1.0.0-javadoc.jar
                │   ├── helloworld-1.0.0-javadoc.jar.md5
                │   ├── helloworld-1.0.0-javadoc.jar.sha1
                │   ├── helloworld-1.0.0-sources.jar
                │   ├── helloworld-1.0.0-sources.jar.md5
                │   ├── helloworld-1.0.0-sources.jar.sha1
                │   ├── helloworld-1.0.0.jar
                │   ├── helloworld-1.0.0.jar.md5
                │   ├── helloworld-1.0.0.jar.sha1
                │   ├── helloworld-1.0.0.pom
                │   ├── helloworld-1.0.0.pom.md5
                │   └── helloworld-1.0.0.pom.sha1
                ├── maven-metadata.xml
                ├── maven-metadata.xml.md5
                └── maven-metadata.xml.sha1

These files plus helloworld-1.0.0.zip should be part of the set of files for attestation. At the moment I've got a working PoC that generates the following subjects file

{
  "attestations" : [ {
    "name" : "helloworld-1.0.0-attestation.intoto",
    "subjects" : [ {
      "name" : "helloworld-1.0.0-javadoc.jar",
      "digest" : {
        "sha256" : "84cd595d2bca1b2a2314f6363933c34407b5d8a2831f3210cc314fbb944da8a4"
      }
    }, {
      "name" : "helloworld-1.0.0-sources.jar",
      "digest" : {
        "sha256" : "46869a25b94dfc1edea8e33915799e9145f1a0e51a18713a0b17d6daac2e6bec"
      }
    }, {
      "name" : "helloworld-1.0.0.jar",
      "digest" : {
        "sha256" : "2f5fdae7243d978ff5f96c20a52a702a86a2cab694d09e8ae2be9fa24ee5c20c"
      }
    }, {
      "name" : "helloworld-1.0.0.zip",
      "digest" : {
        "sha256" : "41c3c3da109bfef484e8214349a9bcc21aa1021249d15e290ac1670c8778627d"
      }
    } ]
  } ],
  "version" : "1"
}

[aalmiray]

I've got a few questions:

1. For the artifacts to be deployed to Maven Central, you'll notice the subjects contain *-sources.jar and *-javadoc.jar. Potentially *-test.jar and any other artifact that's not *.pom, *.asc, maven-metada.xml, or a checksum file will also be automatically included. does this match your expectations for Java projects?
2. The sample java-slsa-generator iterates over a list of artifacts $ARTIFACT_LIST which appears to be supplied as an input https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L50 Where is that list defined?
3. The same generator uploads the subjects to a given location using particular path conventions https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L59-L69 I suppose this is hard requirement, isn't it?

[laurentsimon]

I've got a few questions:

1. For the artifacts to be deployed to Maven Central, you'll notice the subjects contain *-sources.jar and *-javadoc.jar. Potentially *-test.jar and any other artifact that's not *.pom, *.asc, maven-metada.xml, or a checksum file will also be automatically included. does this match your expectations for Java projects?

I'll let @AdamKorcz reply on this one. I think the heuristics were trying to be conservative, so a few more files included in the attestations were deemed acceptable. But I don't think they need to be included.

2. The sample java-slsa-generator iterates over a list of artifacts $ARTIFACT_LIST which appears to be supplied as an input https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L50 Where is that list defined?

Great question. It's defined in https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L42. The funny-looking ${{ fromJson(inputs.slsa-workflow-inputs).artifact-list }} means it's inputs from the TRW which the BYOB framework replays to the callback Action. The TRW input is defined in https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/.github/workflows/trw.yml#L32

3. The same generator uploads the subjects to a given location using particular path conventions https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L59-L69 I suppose this is hard requirement, isn't it?

I don't think this is a hard requirement. I think release-files-for-slsa is used to simplify the call to the upload Action https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L66-L69.

Let me know if you have further questions. Thanks!

[aalmiray]

2. The sample java-slsa-generator iterates over a list of artifacts $ARTIFACT_LIST which appears to be supplied as an input https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L50 Where is that list defined?

Great question. It's defined in https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L42. The funny-looking ${{ fromJson(inputs.slsa-workflow-inputs).artifact-list }} means it's inputs from the TRW which the BYOB framework replays to the callback Action. The TRW input is defined in https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/.github/workflows/trw.yml#L32

That's what I thought. But then I looked at the PW and there's no mention of that parameter which happens to be required by the TRW https://github.com/AdamKorcz/test-java-project/blob/06c3063c945831a74772bb97afe373e4c6c644cc/.github/workflows/main.yml

I suppose the PW & TRW are not in sync at the moment?

[aalmiray]

For the time being, does the subjects file look OK from your POV regardless if it may contain more artifacts that it probably should? JReleaser has a 2 month release cadence with the next release scheduled for April 29th. Would like to get the subjects file generation in that release if possible. If not, that's still OK as the project posts rolling early-access release. Makes it easy for consuming new bits but it's not a stable release.

[laurentsimon]

I suppose the PW & TRW are not in sync at the moment?

I think that's correct. @AdamKorcz?

JReleaser has a 2 month release cadence with the next release scheduled for April 29th. Would like to get the subjects file generation in that release if possible.

@loosebazooka @AdamKorcz can you help? Is it enough to have only the Jar files attested to or do we also need the .pom files? If users install jar files, I think this is enough. If a maven package is made up of more than jar files and additional metadata is needed for installation, maybe some more files are needed to be attested to - and maybe that's why there are some pom files in the subject in @AdamKorcz's POC.

[loosebazooka]

I think the critical objects for maven are the .jar and the .pom and if also dealing with gradle you should include a .module file if found. -sources.jar and -javadoc.jar are nice to have too, maven central requires them anyway. I'm not exactly sure what this .zip file is though (and who is consuming it)?

[aalmiray]

For the time being JReleaser filters .pom, .asc, maven-metadata.xml, and checksum files for all staged artifacts. If there happens to be .module or any other file that's not in the aforementioned explicit list of exclusions then they'll also be picked up.

I can add back .pom.

The .zip is not deployed to Maven Central, rather it's a binary distribution for a CLI app that will be attached to a Github release as a release asset.

[loosebazooka]

gotcha, yeah I think the .pom and gradle .module are on the critical path for artifact consumption and we should have a slsa attestation for the artifact and its defined dependencies. Maven wont create a .module file so you're good if this starts off as a maven only example. I would still consider .module critical for gradle built libraries.

[AdamKorcz]

I would recommend checking out this PoC which demonstrates how to specify the artifacts in the ARTIFACT_LIST: https://github.com/sigstore/sigstore-java/blob/main/.github/workflows/byob-slsa.yaml. The ARTIFACT_LIST should not be limited to .jar files, and is thought to offer flexibility to also attest to pom.xml files or something else.

[AdamKorcz]

I suppose the PW & TRW are not in sync at the moment?

The demo project might be out of sync at times. See this comment for a working PoC: https://github.com/slsa-framework/slsa-github-generator/issues/2035#issuecomment-1518290118

[AdamKorcz]

I don't think this is a hard requirement. I think release-files-for-slsa is used to simplify the call to the upload Action https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L66-L69.

Yes, this is correct. It is merely a step to make it easy for the builder to use the upload action.

[aalmiray]

I would recommend checking out this PoC which demonstrates how to specify the artifacts in the ARTIFACT_LIST: https://github.com/sigstore/sigstore-java/blob/main/.github/workflows/byob-slsa.yaml. The ARTIFACT_LIST should not be limited to .jar files, and is thought to offer flexibility to also attest to pom.xml files or something else.

I see it now https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/.github/workflows/gradle-trw.yml#L27-L30

Notice that artifact-list is an input for java-slsa-framework/gradle-trw but not for slsa-framework/*. Thus I assume it exists to make things easier when running builder/action.yml to collect all artifacts. If this is the case then the JReleaser TRW does not require such input as the configuration file already has the list.

[AdamKorcz]

At the moment I've got a working PoC that generates the following subjects file

@aalmiray using the Java BYOB SLSA-generator?

[aalmiray]

I don't think this is a hard requirement. I think release-files-for-slsa is used to simplify the call to the upload Action https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L66-L69.

Yes, this is correct. It is merely a step to make it easy for the builder to use the upload action.

OK. The question is now: why does the build require the use of the upload action?

Does slsa-framework/slsa-github-generator/.github/workflows/delegator_generic_slsa3.yml@main consume the uploaded artifacts?

[aalmiray]

At the moment I've got a working PoC that generates the following subjects file

@aalmiray using the Java BYOB SLSA-generator?

No, not yet. The PoC is of JReleaser itself for generating the subjects file only.

[AdamKorcz]

I don't think this is a hard requirement. I think release-files-for-slsa is used to simplify the call to the upload Action https://github.com/AdamKorcz/java-slsa-generator/blob/9ba83c8f765d3ca6cc0338c29e044d7b396fbb21/builder/action.yml#L66-L69.

Yes, this is correct. It is merely a step to make it easy for the builder to use the upload action.

OK. The question is now: why does the build require the use of the upload action?

Does slsa-framework/slsa-github-generator/.github/workflows/delegator_generic_slsa3.yml@main consume the uploaded artifacts?

In the case of both the Gradle and the Maven builders, the Upload action is there for projects that make release artifacts available on Github.

They have currently been tested on projects that release on Github.

[aalmiray]

In the case of both the Gradle and the Maven builders, the Upload action is there for projects that make release artifacts available on Github.

They have currently been tested on projects that release on Github.

Ah OK, then I don't need to upload artifacts in the same way, as creating GitHub releases is one JReleaser's responsibilities. Thanks!

[laurentsimon]

Thanks @AdamKorcz for the prompt reply!

[aalmiray]

UPDATE

PoC has successfully built a Maven project, created a GitHub release with JReleaser, and attestations using a TRW with the slsa-delegate.

TRW is accessible at https://github.com/jreleaser/jreleaser-java-slsa-generator Sample project accessible at https://github.com/aalmiray/helloworld-java-bin Release run https://github.com/aalmiray/helloworld-java-bin/actions/runs/4800832624 Release at https://github.com/aalmiray/helloworld-java-bin/releases/tag/v1.0.0

Assumptions:

• PW invokes TRW with minimum configuration https://github.com/aalmiray/helloworld-java-bin/blob/519b3d2915963ab11bb47f14ce5856c99f7158da/.github/workflows/release.yml#L39-L51
• You'll notice TRW declares a github-token secret. This is to test mapping secrets. In the future a project may publish artifacts to other repositories (such a homebrew tap) thus a GH PAT is needed, the default GITHUB_TOKEN is not enough.
• It's expected that the release configuration contains build instructions so that the builder action makes less assumptions on the build. This is accomplished with https://github.com/aalmiray/helloworld-java-bin/blob/519b3d2915963ab11bb47f14ce5856c99f7158da/jreleaser.yml#L1-L8 Projects that consume this TRW must have similar build instructions. This sample project relies on Maven but it might as well could be Gradle.
• TRW currently performs its own checkout because of fetch-depth: 0. This will be removed in the future. See #2043
• TRW is capable of configuring a given version of Java and cache dependencies for the specified build tool https://github.com/jreleaser/jreleaser-java-slsa-generator/blob/799ca275aad9e3f8245c293df227556527ec0437/builder/action.yml#L26-L31
• TRW currently calculates subject attestations. This will be done automatically by JReleaser (https://github.com/jreleaser/jreleaser/issues/1349 PoC for this not yet merged).

Notes:

• Apparently attestations are uploaded as artifacts to the top level action. I was expecting them to be uploaded to the latest release. I suppose this step has yet to be implemented?

Furthermore, uploading to an existing release requires passing the matching tag (JReleaser or maven-release-plugin create the tag), likely also define the name for the attestation file.

[laurentsimon]

Looks great!

Apparently attestations are uploaded as artifacts to the top level action. I was expecting them to be uploaded to the latest release. I suppose this step has yet to be implemented?

Good question. Until now, we've considered it the job of the TRW to upload, see https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/.github/workflows/slsa3.yml#L138-L162. I think you're right that we could upload to the GH release assets. But given that the TRW may want to upload the provenance to a registry as well - and SRW does not have context about the various use cases - we have till now decided to leave it up to the TRW to use the provenance as it sees fit.

Wdut of this decision?

None of this is set in stone, so we're happy make changes if need be.

[aalmiray]

Well, as long as the attestation artifact is known I suppose the TRW could do the upload. But also considering this may be a common operation for several TRWs why not make it an optional task of the generator? That way there's less repetition among TRWs and they'll still have the choice to upload attestation to any other location they deem necessary.

[laurentsimon]

Here's the code we use for uploading https://github.com/slsa-framework/slsa-github-generator/blob/main/.github/workflows/builder_nodejs_slsa3.yml#L287-L308 - in fact we tend to copy it in multiple workflows, so having the SRW do it could be something to consider

[aalmiray]

One more thing, I noticed that the generic generator does not upload attestations to releases marked as prerelease, even if that's the latest release that was just tagged. That's the reason why I had to explicit define a tag in

https://github.com/jreleaser/jreleaser/blob/819f18e08905a80e6b990e0e37f4975c20ba3103/.github/workflows/early-access.yml#L112-L120

The same should be taken into account in the delegate SRW if auto-upload to release is added.

[laurentsimon]

Thanks for the feedback, very useful. We have added some support for in nodejs builder https://github.com/slsa-framework/slsa-github-generator/blob/main/.github/workflows/builder_nodejs_slsa3.yml#L292, but not in generic generator. Created https://github.com/slsa-framework/slsa-github-generator/issues/2061 for tracking.

Created https://github.com/slsa-framework/slsa-github-generator/issues/2062 for TRW upload feature.

Anything needed from us for additional testing?

[aalmiray]

Thanks! The last remaining item is supporting more secrets, tracked by #1790

[laurentsimon]

One comment about the integration https://github.com/jreleaser/jreleaser-java-slsa-generator/blob/main/builder/action.yml#L53

Our original intention was to call the original Action like in https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/internal/sbom-wrapper/action.yml#L45 (not a hard requirement, but simplifies audits of code if all refs are the same). This ensures that the ref / sha of the reusable workflow is the same as he Action. Since you're using a separate repository, that's not possible in your case.

Are you planning on keeping a separate repository or you imagine integrating it in the main https://github.com/jreleaser/release-action repo?

[aalmiray]

I see. I'll move the TRW to jreleaser/release-action once https://github.com/jreleaser/jreleaser-java-slsa-generator/issues/1 is completed.

[aalmiray]

@laurentsimon While updating the existing JReleaser BYOB to comply with latest changes I noticed I may have the need for the builder to expose custom outputs to the TRW.

The JReleaser build may create a tag as part of its build process. This tag may not be known by the TRW ahead of time, thus the builder should provide it as an output. For this to work the SLSA delegator should grab any outputs form the builder and pass them back to the TRW, likely using a JSON structure just like inputs are handled from TRW to builder.

For additional context, if the JReleaser TRW doesn't know the resulting tag then it cannot upload the computed attestation file to a given GitHub release.

https://stackoverflow.com/questions/73702333/github-actions-reuse-outputs-from-other-reusable-workflows

[laurentsimon]

That makes sense. We already return the entire output of the Action https://github.com/slsa-framework/slsa-github-generator/blob/main/.github/workflows/delegator_generic_slsa3.yml#L59-L61. Does it work for you? You'll have to use fromJson() I think to retrieve it properly.

[aalmiray]

Gotcha. Will give it a try.

One more thing of note regarding reproducible outcome. The use of @main for invoking the SRW and by the SRW for its internal components could potentially lead to non reproducible outcomes.

Will there be versioned (most likely via shas) in the future?

[laurentsimon]

You're right. We ask TRW to use @main until we release a version. Internally, we use @main during development and change the refs to a tag before a release, see https://github.com/slsa-framework/slsa-github-generator/pull/2118 as example.

We don't use @hash due to https://github.com/slsa-framework/slsa-github-generator#referencing-slsa-builders-and-generators. Theoretically we might be able to use @hash for internal Actions.

[aalmiray]

One comment about the integration https://github.com/jreleaser/jreleaser-java-slsa-generator/blob/main/builder/action.yml#L53

Our original intention was to call the original Action like in https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/internal/sbom-wrapper/action.yml#L45 (not a hard requirement, but simplifies audits of code if all refs are the same). This ensures that the ref / sha of the reusable workflow is the same as he Action. Since you're using a separate repository, that's not possible in your case.

Are you planning on keeping a separate repository or you imagine integrating it in the main https://github.com/jreleaser/release-action repo?

@laurentsimon circling back to this. As suggested, the repository for a builder action (such as jreleaser/release-action) should host the TRW to align refs/shas. This couples the release/update cycle of the action and the TRW, as tagging the repo applies to everything in that particular ref. For a single action + TRW combo that might not be much of a problem. However, JReleaser has the potential to offer multiple TRWs (Java, Rust, C#, etc), thus things get more complicated.

I'm thinking one possible solution for keeping action + TRW together while differentiating between TRW releases would be to set a branch per TRW, where the only code shared between these branches is the main action, such that:

Java builder

  release:
    needs: [ precheck ]
    permissions:
      contents: write
      id-token: write
      actions: read
      packages: write
    uses: jreleaser/release-action/.github/workflows/builder_slsa3.yml@java
    with:
      project-version: ${{ needs.precheck.outputs.VERSION }}
      rekor-log-public: true
    secrets:
      github-token: ${{ secrets.GITHUB_TOKEN }}

Rust builder

  release:
    needs: [ precheck ]
    permissions:
      contents: write
      id-token: write
      actions: read
      packages: write
    uses: jreleaser/release-action/.github/workflows/builder_slsa3.yml@rust
    with:
      project-version: ${{ needs.precheck.outputs.VERSION }}
      rekor-log-public: true
    secrets:
      github-token: ${{ secrets.GITHUB_TOKEN }}

The alternative of course is to store TRWs in separate repositories but that complicates audits.

WDYT?

[laurentsimon]

How would you version each "branch" in this case?

You're hitting the same limitation we're having in this repo. We have multiple builders, but a single versioning scheme. The way we've gone about it (in no way perfect) is that we try to rarely release MAJOR (breaking) updates: this way if you release an update for Rust builder, the users of Java builders can safely update. In the release notes we mention whhich builder the update is for; and sometimes explicitly say that there is no changes to other builders. That could be one possibility. How frequently do you make MAJOR updates to the code?

[aalmiray]

I was thinking that branch tags would have to use a prefix, such that tags for java would be java-x.y.z.

Branches should be independent from one another. The java branch has no code from the rust branch. This means consumers won't get updates for Rust if they happen to consume the Java branch or tags. I suppose I can get away from it much easily as these TRWs should share less code. In your case there's plenty of shared code for good reasons.

[laurentsimon]

I was thinking that branch tags would have to use a prefix, such that tags for java would be java-x.y.z.

Would this break updates from dependabot and renovatebot? Users won't receive updates, will they?

I suppose you can use semver with optional info, but then it's back to the original problem...

If we can document how to receive updates for renovate bot (they have support for manually-added logic), that could work. @rarkins may have some pointers

[rarkins]

Hi, Renovate supports "extracting" a version from a complex tag, e.g. extracting x.y.z from java-x.y.z. I've had a skim through this thread and I'm not sure though if I understand where that x.y.z would be referenced elsewhere, so I can't answer for sure about what you're doing - can anyone clarify?

[aalmiray]

Sure. A repository may contain multiple TRWs that are independent from one another. Usually one would use separate repos to have each component follow their own lifecycle. However, for TRWs it would be better to host them at the same repo where the main action is hosted.

The idea is then organize these independent TRWs on their own branch (java, rust, etc) using a prefix tag (java-1.2.3, rust-4.5.6) to identify specific TRW releases.

[rarkins]

So in the downstream repos the strings java-1.2.3 and rust-4.5.6 would be used, not 1.2.3 and 4.5.6?

[aalmiray]

@rarkins that is correct.

[rarkins]

We can probably get it to work, however it would be easier if it was 1.2.3-java, 4.5.6-rust similar to how Docker images frequently do it and Maven images sometimes do it (i.e. the suffix indicates compatibility and not instability)

[aalmiray]

OK, so let's make it a suffix instead of a prefix 😅

[aalmiray]

@laurentsimon I've updated https://github.com/jreleaser/jreleaser-java-slsa-generator/ with the latest changes. The TRW now uploads the resulting attestation to the recently created Github release. So far so good. However, I've encountered an issue when attempting provenance verification

$ ~/Downloads/slsa-verifier-darwin-amd64 version
  ____    _       ____       _             __     __  _____   ____    ___   _____   ___   _____   ____
 / ___|  | |     / ___|     / \            \ \   / / | ____| |  _ \  |_ _| |  ___| |_ _| | ____| |  _ \
 \___ \  | |     \___ \    / _ \    _____   \ \ / /  |  _|   | |_) |  | |  | |_     | |  |  _|   | |_) |
  ___) | | |___   ___) |  / ___ \  |_____|   \ V /   | |___  |  _ <   | |  |  _|    | |  | |___  |  _ <
 |____/  |_____| |____/  /_/   \_\            \_/    |_____| |_| \_\ |___| |_|     |___| |_____| |_| \_\
slsa-verifier: Verify SLSA provenance for Github Actions

GitVersion:    2.3.0
GitCommit:     c9abffe4d2ab2ffa0b2ea9b2582b84164f390adc
GitTreeState:  clean
BuildDate:     2023-05-10T00:48:36
GoVersion:     go1.18.10
Compiler:      gc
Platform:      darwin/amd64

$ SLSA_VERIFIER_EXPERIMENTAL=true ~/Downloads/slsa-verifier-darwin-amd64 verify-artifact ~/Downloads/helloworld-1.0.0.zip --provenance-path ~/Downloads/helloworld-1.0.0-attestation.intoto.sigstore --source-uri https://github.com/aalmiray/helloworld-java-bin
Verifying artifact /Users/aalmiray/Downloads/helloworld-1.0.0.zip: FAILED: untrusted reusable workflow: slsa-framework/slsa-github-generator/.github/workflows/delegator_generic_slsa3.yml got true

FAILED: SLSA verification failed: untrusted reusable workflow: slsa-framework/slsa-github-generator/.github/workflows/delegator_generic_slsa3.yml got true

Release found at https://github.com/aalmiray/helloworld-java-bin/releases/tag/v1.0.0 Build found at https://github.com/aalmiray/helloworld-java-bin/actions/runs/5091748523

[laurentsimon]

Hi great!

verification: the slsa-verifier version you use does not support verification yet. We're adding support:

• [ ] We currently expect the tag to be of the form vx.y.z. We will update this for you as an exception. I need to check if vx.y.z-<xxx> is typically valid for prod releases (I know that vx.y.z-rc is not, for example) https://github.com/slsa-framework/slsa-verifier/issues/625, i which case we could allow it for everyone builder.
• [ ] We need to update the generator format with https://github.com/slsa-framework/slsa-github-generator/issues/2186. The verifier already checks that (https://github.com/slsa-framework/slsa-verifier/pull/621), but the generators are not in sync.
• [ ] We need to add support for testing in verification https://github.com/slsa-framework/slsa-verifier/issues/602
• [ ] https://github.com/slsa-framework/slsa-verifier/issues/600

So I think you need to wait for us to complete these items. I'll ping back once I have resolved the issues above for you to test.

[ianlewis]

Hi @aalmiray,

The alternative of course is to store TRWs in separate repositories but that complicates audits.

I'm curious how using separate repositories complicates audits? especially if the different branches don't share code?

I think this might be a bit confusing for users since you'll effectively have multiple default branches on your repo, and I'm a bit wary of adding special support for this in the BYOB framework if it's only likely to be consumed by JReleaser.

[aalmiray]

@ianlewis the issue regarding separate repositories came from here https://github.com/slsa-framework/slsa-github-generator/issues/2035#issuecomment-1524363920

[ianlewis]

@ianlewis the issue regarding separate repositories came from here #2035 (comment)

I see. So part of the issue is that the jreleaser/release-action is used for both Java and Rust? Could you just have different workflow files for the java and rust builder in the default branch? i.e. builder_java_slsa3.yml and builder_rust_slsa3.yml?

[aalmiray]

My goal is to have different workflow files for each language, along with their respective builder action and supporting scripts (when needed). Yet, each workflow/builder combination is independent from one another and in theory should have separate release cycles, hence the suggestion to use different branches and tags such that a tag like 1.2.3-java makes sense only for a Java workflow/builder and not Rust.

[laurentsimon]

@aalmiray we merged a PR for the actions/delegator/secure-upload-folder and actions/delegator/secure-download-folder. You should be able to reference them @main for now and test them. We also merged a BYOB.md which should contain most of the necessary docs. Feel free to create issues if the docs are not good enough.

[aalmiray]

Thank you @laurentsimon! Will check them out shortly. What's the status of the verify step via CLI? I think that's the last hurdle I encountered.

[laurentsimon]

I've sent https://github.com/slsa-framework/slsa-verifier/pull/644 to allow verification with tags of the form vx.y.z-<language>. Feel free to comment on the PR.