Add SLSA provenance via build script

[pnacht]

Hey, I'm Pedro and I'm working on behalf of Google and the Open Source Security Foundation (OpenSSF). Given the significant increase in supply-chain attacks, the OpenSSF is focused on improving the security of the open-source ecosystem as a whole. For example, #792 was based on feedback from Scorecards, an OpenSSF tool.

The OpenSSF has also developed the SLSA specification for projects to attest to a published artifact's provenance, allowing its consumers to ensure that the artifact comes from a trusted source. There are also GitHub workflows to securely generate this provenance and CLI tools to verify an artifact's authenticity.

Given how Jackson is almost synonymous with JSON in the Java ecosystem, the OpenSSF has placed Jackson on its list of the 100 most important open-source projects. I'd therefore like to offer to help jackson-core incorporate SLSA into its deploy workflow.

Would you be interested in a PR to adopt SLSA?

[cowtowncoder]

Hi @pnacht! I don't know much about SLSA, but in principle it sounds like something that could prove useful.
Usually the biggest question is effort involved in workflow; how much change is needed etc.
If there is little additional overhead from maintainer perspective I think we'd be +1.

So I think we can definitely start discussion. I hope to read a bit more about SLSA over the holidays.

Looking forward to collaboration!

[pnacht]

Hey @cowtowncoder, good to hear!

Hope you had a nice Thanksgiving and some time to recover!

Java provenance is currently generated using the SLSA generic generator. This involves adding two "parts" to the workflow: one step immediately after the deploy to calculate the hashes for the relevant jars, and a separate job (for security reasons) to generate the provenance.

If you'd be interested, I've actually already made the requisite changes in a fork, I'd be happy to submit a PR for you to take a look.

---

Or, if you'd first like to take a look at how the workflow works, see a successful run here. That run was on a slightly different version of the workflow than would be in the PR since my fork naturally can't deploy, so it instead uploads the jars as a workflow artifact.

The .intoto.jsonl file is the provenance. It's a JSON file, but the most important value ("payload") is a base64'd json blob. If you want to glance at it, I'd suggest using jq:

jq -r '.payload | @base64d' jackson-core-2.14.0-SNAPSHOT.intoto.jsonl | jq

There's a lot of information there, so if you want, I can write up a little summary of the most relevant bits.

[cowtowncoder]

A summary would be nice. I think PR would also make sense as it'd be a bit easier to see how CI changes look like (and how is triggering done).

Thank you!

[pnacht]

@cowtowncoder I've submitted the PR!

So, using the .intoto.jsonl provenance file from the run I mentioned earlier, we can run the following command (or use the Rekor link mentioned at the very bottom):

jq -r '.payload | @base64d' jackson-core-2.14.0-SNAPSHOT.intoto.jsonl | jq

This outputs the entire provenance, the most relevant parts of which are:

• "subject" identifies both jars (jackson...jar and jackson...-sources.jar), along with their SHAs
• "predicate" shows a bunch of information regarding how the jars were built, most interestingly:
  • "builder" shows the provenance was generated with the "generic generator" (used for languages without a SLSA builder)
  • "invocation" shows the jars were created from my fork's 2.14 branch, at a specific commit, using the main.yml workflow
• "materials" at the end also describes the "subjects", but by pointing at the "ingredients" used to generate them, not just their names. In the case of jackson-core, that's just the repo itself.

{
  "#": "...",
  "subject": [
    {
      "name": "jackson-core-...-sources.jar",
      "digest": {
        "sha256": "4be0c..."
      }
    },
    {
      "name": "jackson-core-....jar",
      "digest": {
        "sha256": "f7f0e..."
      }
    }
  ],
  "predicate": {
    "builder": {
      "id": "https://.../generator_generic_slsa3.yml@refs/tags/v1.2.2"
    },
    "buildType": "https://.../slsa-github-generator/generic@v1",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/pnacht/jackson-core@refs/heads/2.14",
        "digest": {
          "sha1": "51259..."
        },
        "entryPoint": ".github/workflows/main.yml"
      },
      "#": "...",
    },
    "materials": [
      {
        "uri": "git+https://github.com/pnacht/jackson-core@refs/heads/2.14",
        "digest": {
          "sha1": "51259..."
        }
      }
    ]
  }
}

To ensure this information can't be falsified, the provenance is also published to an append-only transparency log. For example, looking at the compiled jar: https://rekor.tlog.dev/?hash=f7f0ee170a600c1f6d34916990c51bc88dbbd0dbb216351cbbdeed4ff3de8e6e

Here we can again see the same provenance attestation (click "Attestation" at the end) as well as a bunch of other information confirming this "release" was published via the "expected" channel (a GitHub Action on my fork).

[cowtowncoder]

Doh! Forgot to use the release script for 2.15.0-rc1.... need to make sure to use it for 2.15.0-rc2 just to verify before 2.15.0 final.

[pnacht]

Happens to the best of us!

…

On Sat, Mar 18, 2023 at 5:27 PM Tatu Saloranta ***@***.***> wrote: Doh! Forgot to use the release script for 2.15.0-rc1.... need to make sure to use it for 2.15.0-rc2 just to verify before 2.15.0 final. — Reply to this email directly, view it on GitHub <#844 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUEE3XWKWBUR65OBWA632TW4YLBDANCNFSM6AAAAAASJNLA6A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cowtowncoder]

@pnacht Ok, hmmh. So, we are missing a Secret for workflow to access it seems:

https://github.com/FasterXML/jackson-core/actions/runs/4546942534

with this being the error:

    gpg: no default secret key: No secret key
    gpg: signing failed: No secret key

wonder what would be the fix here? Locally it... "just works".

EDIT I deleted jackson-core-2.15.0-rc2 tag. Depending on timing, may need to push this one, too, manually. But will wait a bit first.

[cowtowncoder]

Oh. I have never uploaded GPG secret since I've never needed it in Github action. I only have them locally....

Hopefully I'll be able to do what this says:

https://stackoverflow.com/questions/61096521/how-to-use-gpg-key-in-github-actions

(trying it out now)

[cowtowncoder]

Looks like things get bit further, now failing with:

Error: ROR] Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:3.0.1:sign (sign-artifacts) on project jackson-core: Unable to decrypt gpg passphrase: org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException: java.io.FileNotFoundException: /home/runner/.m2/settings-security.xml (No such file or directory) -> [Help 1]