Trustification Blog

Trustify: Release 0.3.2

2025-07-04T00:00:00.000Z

Today we released Trustify 0.3.2, exactly one year after 0.1.0-alpha.10. Read on to learn what's new and what happened in the last year.

The past year

Time flies when you're having fun! It seems we've been so focused on development that we didn't pay much attention to the blog. During this time, we had the 0.2.z release train, which served as the foundation for Red Hat Trusted Profile Analyzer 2.0. We also started working on the 0.3.z stream, which brings us to today's release.

New and noteworthy

Since we didn't cover any previous 0.3.z releases, let's focus on the 0.3 series in general. Here's what's new:

Enhanced Analysis Endpoint - Provides a fast way to search SBOMs and their relationships, even across multiple SBOMs
Quay Integration - Added support for importing SBOMs from Quay instances
Improved Labels Experience - Enhanced labeling functionality for better organization and filtering
UI Modernization - Updated the user interface to PatternFly 6 for a more modern and consistent experience
OpenShift Data Foundation Compatibility - Ensured full compatibility with OpenShift Data Foundation
License Reports - New reporting capabilities for license information and compliance
Performance and Stability - The usual bug fixes and performance improvements to keep everything running smoothly

What's next?

We recommend trying out the new version! In "Trying out Trustify, on a local machine", we introduced a quick and easy way to get started within minutes.

And of course:

Check out the release 0.3.2 on GitHub
Reach out to us on Matrix and let us know what you think

Trustify: Release 0.1.0-alpha.10

2024-07-04T00:00:00.000Z

Today we released Trustify 0.1.0-alpha.10. It's another alpha release as part of our weekly release cadence. Read on to learn what's new.

New and noteworthy

There are more labels that get applied during the upload process. It also is possible to automatically add labels using the importer configuration.
The system will now also record the SHA384 and SHA512 digests of uploaded documents.
The package API endpoint and corresponding UI have been renamed to "PURL".

The reason for that is pretty simple, the discussion was not. Right now, these "packages" actually had been "PURLs", and not much more. That led to confusion about what arguments to pass in, and what information to expect back.

For the future, we still want to collect information about packages, outside the context of an SBOM. However today, that model didn't work well.
In addition to titles, also descriptions will be returned now for advisories. As many advisories don't have a title, this allows the UI to render a title, based on those descriptions instead.
Allow setting labels during the upload of a document.
There are some incompatible changes to the database migration. While our goal is to provide migrations as good as possible, this change was simply too big. So, as we are still in an alpha cycle, the decision was made to simply update the schema in a breaking way.
The UI can show the relationship between package and vulnerabilities for each entity

What's next?

Of course, we would recommend you try out the new version! In "Trying out Trustify, on a local machine", we introduced a quick and easy way to get there within minutes.

And of course:

Check out the release 0.1.0-alpha.10.
Reach out to us on Matrix, and let us know what you think.

Trying out Trustify, on a local machine

2024-06-27T00:00:00.000Z

Trustify is a project for working with software supply chain information, like SBOMs and advisories. Connect a few data sources with the system, and gather some insight in what you have.

Although Trustify is in its pretty early stages, it might be interesting to try it out and play a bit with it, do see where this is heading. Read on to see how you can easily do that.

What to expect?

First of all, we really want to emphasize that the project is pretty young. There are a lot of areas where work is underway. However, in the sprit of "release early, release often", we try to release a version every week. In a form that you can simply download and run it right away.

That, of course, is not the ideal deployment scenario. But it should enable you to get started within minutes and see what's in the box.

What do you need?

A computer (doesn't work on phones, sorry), internet access (we don't ship on floppies), and the ability to run some code on your machine (yes, corporate IT rules might be an issue).

Linux, macOS, Windows. AMD or ARM. Doesn't make a difference.

Everything, Everywhere, All at once

Head over to the release page, and pick a binary for your OS and architecture with the name starting with trustd-pm. That's a binary which includes just everything: the application itself, the UI, the database, and an embedded OIDC server.

Download that archive, extract it, and run the binary inside it. That's it!

Now what?

Take your favorite web browser and navigate to: http://localhost:8080. That will automatically log you in with a demo user, and show you the user interface.

You might notice that the system looks quite empty. That is because we did not connect any datasource yet. Navigate to the "Importer" section and enable the following pre-configured importers:

cve-from-2024
redhat-csaf-vex-2024
redhat-sbom

After that, you might want to take a break. Ingesting those sources for the first time might take a bit. Future runs, however, will be much faster, as only the diff will be processed.

Maybe click a bit around in the UI to get an idea. Again, don't expect too much yet. It's'a work in progress.

So?

Being a work in progress also has its advantages. If you managed to get the system up and running in a few minutes, you might want to reach out and check what we're up to. Or you might have some ideas yourself, or questions. Or, in case you had not been able to start up the demo, we would kindly as to reach out to use and let us know.

Everything is on GitHub: https://github.com/trustification/trustify. If you have some feedback or run into problems, just raise an issue. If you have some ideas, please let us know as well. And of course, PRs are also always welcome.

If you're looking for a direct chat, you're also welcome to join our Matrix channel: #trustification:matrix.org.

What's next?

Our goal is to push out a new pre-release every week around Thursday. So maybe come back in a bit and check out the improvements.

The CycloneDX Maven Aggregate SBOM and why you shouldn't trust it (yet)

2023-03-20T00:00:00.000Z

Over the last few months I've spent a lot of time with the CycloneDX Maven Plugin, trying to prove it is suitable for us to use as part of securing the Software Supply Chain. I've discovered and fixed a number of issues, related to the generation of an SBOM for each project using the makeBom goal, and have now turned my focus to aggregates and the makeAggregateBom goal.

I'll start this post with a description of what I believe an aggregate SBOM should contain. This may be different to what you are looking for, if so I would like to hear about your expectations and tailor my fix to address your needs. In any case I believe the issues I am about to describe will likely impact yourselves and create enough doubt in the accuracy of the aggregate SBOM for you to decide not to trust it.

Generating an SBOM for an individual project is fairly straight forward, you run the makeBom goal and create an SBOM representing the build time dependency graph for your component. You can choose to filter certain artifacts and/or scopes from the SBOM, however the dependency resolution will still be impacted by all the dependencies within the project.

When generating SBOMs for a multi-module project you have two choices

generate an SBOM for each individual project
generate an aggregate SBOM which represents all projects within your multi-module project

My expectation is the aggregate SBOM would be an aggregate of all the individual SBOMs, in other words each component present in the individual SBOMs should be present in the aggregate SBOM and each dependency tree represented in the individual SBOMs should also be present in the aggregate SBOM.

What do we get from the current aggregate SBOM?

Before we describe what happens it is important to understand the CyloneDX specification requires a component to specify a bom-ref attribute if the component is to be referenced elsewhere in the SBOM, with the bom-ref being unique across the set of components. The CycloneDX maven plugin will always generate a bom-ref for each component, currently the same as the component purl, and will use this reference when creating the dependency hierarchy.

Now to the details.

When generating an aggregate SBOM the plugin will iterate over all the projects within the multi-module build (the reactor), generate an SBOM for each project and combining this with the previous SBOMs. It will continue until each project within the reactor has been processed, resulting in an aggregate SBOM. On the surface this appears to be the right thing to do, all components and all dependencies should be included in the SBOM and this is what we want ..... only the details are more subtle.

What actually happens when we combine the components and dependencies from a project is the plugin will iterate over each component, adding it to the set of known components if it has not previously encountered its bom-ref, and in the case of dependencies it will add all project dependencies to the set of known dependencies within the aggregate. Now I know what you are thinking! This still appears to be correct, so where is it going wrong? To understand that we need to look at the Dependency class.

The Dependency class defines equality only on the content of its ref attribute, so when adding dependencies to a Set the following are considered to be the same.

and

What this means is the first dependency added to the set of all dependencies will be the winner, will be part of the generated SBOM, and all subsequent dependency hierarchies will be lost. But wait, shouldn't a component always have the same dependencies on other components? This is certainly the assumption made in the plugin, unfortunately it is not a valid assumption for many reasons and for this we need to look more at how maven handles dependency resolution. Scenarios where this assumption is invalid include

the component is included in a project with a different set of dependencies
the component is included in a project which specifies dependencies in a different order
the component includes dependencies on artifacts with test or provided scope, or includes dependencies on artifacts marked as optional
there is a dependency management section overriding the version of an artifact
there is a dependency management section excluding dependencies from an artifact

There are likely more scenarios, however the above are reasonably common and sufficient to demonstrate the problem. In the next sections we will go through examples for each of the top three, ignoring version management, so we can demonstrate how easy it is to fall into this trap and explore the impact on the generated aggregate SBOM.

Differing Sets of Dependencies

In this scenario we will take a look at a multi-module project where an external project is consumed within the context of differing sets of dependencies. Project dependency_A will consume the artifact we are interested in, dependency_C, alongside a second dependency, dependency_E, which will cause a version conflict which needs to be resolved by the maven conflict resolution mechanism. Project dependency_B will simply consume dependency_C as is, without there being any conflict needing to be resolved.

Let us now take a look at the dependency hierarchy for both projects, as visualized through the dependency:tree plugin. For dependency_A we see

com.example.example1:dependency_A:jar:1.0.0
+- com.example.external:dependency_C:jar:1.0.0:compile
|  \- com.example.external:dependency_D:jar:1.0.0:compile
|     \- (com.example.external:dependency_E:jar:1.0.0:compile - omitted for conflict with 2.0.0)
\- com.example.external:dependency_E:jar:2.0.0:compile (scope not updated to compile)
   \- com.example.external:dependency_F:jar:2.0.0:compile

and for dependency_B we see

com.example.example1:dependency_B:jar:1.0.0
\- com.example.external:dependency_C:jar:1.0.0:compile
   \- com.example.external:dependency_D:jar:1.0.0:compile
      \- com.example.external:dependency_E:jar:1.0.0:compile
         \- com.example.external:dependency_F:jar:1.0.0:compile

In the first project we see the maven dependency resolution mechanism has aligned the version of dependency_E referenced in the tree to version 2.0.0, this was chosen because this dependency is closer to the root of the tree.

Let's now take a look at what we see in the aggregate SBOM.

From the above we see there is a flow matching A1->C1->D1->E2->F2 and A1->E2->F2, so the aggregated SBOM correctly represents the dependency hierarchy for dependency_A.

If we now look at how the dependency tree for dependency_B is represented we see a problem. The representation for dependency_B is a flow from B1->C1->D1->E2-F2 which does not match the dependency hierarchy for dependency_B; it should be B1->C1->D1->E1->F1! Where has the flow E1->F1 gone? Unfortunately this flow is now orphaned with E1 being its own root in the SBOM!

Differing Order of Dependencies

In this scenario we will take a look at a multi-module project where we have two projects consuming the same sets of dependencies, but specifying those dependencies in opposite order within their respective pom.xml files. The first will declare a dependency on dependency_C followed by deependency_D whereas the second will declare a dependency on dependency_D followed by dependency_C. Both dependency_C and dependency_D will consume dependency_E but with different versions, causing a conflict which needs to be resolved.

Let us now take a look at the dependency hierarchy for both projects, as visualized through the dependency:tree plugin. For dependency_A we see

com.example.example2:dependency_A:jar:1.0.0
+- com.example.external:dependency_C:jar:1.0.0:compile
|  \- com.example.external:dependency_E:jar:1.0.0:compile
|     \- com.example.external:dependency_F:jar:1.0.0:compile
\- com.example.external:dependency_D:jar:1.0.0:compile
   \- (com.example.external:dependency_E:jar:2.0.0:compile - omitted for conflict with 1.0.0)

and for dependency_B we see

com.example.example2:dependency_B:jar:1.0.0
+- com.example.external:dependency_D:jar:1.0.0:compile
|  \- com.example.external:dependency_E:jar:2.0.0:compile
|     \- com.example.external:dependency_F:jar:2.0.0:compile
\- com.example.external:dependency_C:jar:1.0.0:compile
   \- (com.example.external:dependency_E:jar:1.0.0:compile - omitted for conflict with 2.0.0)

In the first project we see the maven dependency resolution mechanism has aligned dependency_E with version 1.0.0 while in the second project the resolution mechanism has aligned dependency_E with version 2.0.0. Since both versions of dependency_E appear at the same depth it is the one which is first included in the dependency tree which will win.

Let's now take a look at what we see in the aggregate SBOM.

From the above we see there is a flow matching A1->C1->E1->F1 and A1->D1->E1->F1, so the aggregated SBOM correctly represents the dependency hierarchy for dependency_A.

If we now look at how the dependency tree for dependency_B is represented we can again see a problem. The representation for dependency_B has flows from B1->D1->E1-F1 and B1->C1->E1->F1 which do not match the dependency hierarchy for dependency_B since it does not include E1->F1 in its hierarchy! Where has the flow E2->F2 gone? Unfortunately this flow is now orphaned with E2 being its own root in the SBOM!

Non Transitive Dependencies

In this scenario we will take a look at how non-Transitive dependencies can impact the normal resolution process, and therefore the derived dependency trees. The non-Transitive dependencies could be those dependencies with scopes of either provided or test, or could be dependencies which are marked as being optional.

Project dependency_A will declare a dependency on dependency_C alongside an optional dependency on dependency_E, which causes a conflict which needs to be resolved. Project dependency_B will have a single dependency on dependency_A, consuming it as is.

Let us now take a look at the dependency hierarchy for both projects, as visualized through the dependency:tree plugin. For dependency_A we see

com.example.example3:dependency_A:jar:1.0.0
+- com.example.external:dependency_C:jar:1.0.0:compile
|  \- com.example.external:dependency_D:jar:1.0.0:compile
|     \- (com.example.external:dependency_E:jar:1.0.0:compile - omitted for conflict with 2.0.0)
\- com.example.external:dependency_E:jar:2.0.0:compile (scope not updated to compile)
   \- com.example.external:dependency_F:jar:2.0.0:compile

and for dependency_B we see

com.example.example3:dependency_B:jar:1.0.0
\- com.example.example3:dependency_A:jar:1.0.0:compile
   \- com.example.external:dependency_C:jar:1.0.0:compile
      \- com.example.external:dependency_D:jar:1.0.0:compile
         \- com.example.external:dependency_E:jar:1.0.0:compile
            \- com.example.external:dependency_F:jar:1.0.0:compile

In the first project we see the maven dependency resolution mechanism has aligned dependency_E with version 2.0.0 through the transitive dependency inherited via the optional dependency. In the second project the maven dependency resolution mechanism has ignored the optional dependency leaving the original dependency on dependency_E:1.0.0.

Note: While this example is making use of an optional dependency, the same tree would be generated if this dependency was of scope test or provided.

Let's now take a look at what we see in the aggregate SBOM.

From the above we see there is a flow matching A1->C1->D1->E2->F2 and A1->E2->F2, so the aggregated SBOM correctly represents the dependency hierarchy for dependency_A.

If we now look at how the dependency tree for dependency_B is represented we see a problem. The representation for dependency_B includes flows from B1->A1->C1->D1->E2->F2 and B1->A1->E2->F2, neither of which match the dependency hierarchy for B; the hierarchy for dependency_B should be a flow of B1->A1->C1->D1->E1->F1! Not only has the flow E1->F1 been orphaned from the dependency_B dependency tree, and now its own root, but the SBOM claims dependency_B has multiple dependency flows when it should only be a single flow.

Summarising the issue

We see from the above scenarios it is reasonably easy to end up with a multi-module project which results in an invalid expression of the project dependency trees within the aggregated SBOM, and we have still to look at exclusions and version management through the maven dependencyManagement declarations. To make matters worse we have no easy way of identifying whether the aggregated SBOM contains an invalid dependency graph. While it is possible the aggregated SBOM could contain orphaned dependency trees it is also possible those dependency trees would be consumed by other components within the SBOM.

Given the aggregate SBOM is no longer reliable the only safe approach is to rely on the individual SBOMs for each project, at least for now.

How can we solve this?

There is a solution for this, however the solution comes with implications which may break some tools which work with SBOMs. These tools will already be making invalid assumptions, and we will have to work with their authors to identify and fix any occurrences we find.

What is really lacking in the CycloneDX specification is a way in which we can easily describe alternative dependency hierarchies for a component, since as we have shown this is something which happens within the java space and likely other areas.

The CyloneDX specification defines the component dependency hierarchies by referring to the components themselves, through their references, however this reference also defines the unique hierarchy within the dependencies section. For example

The ref attribute pkg:maven/org.owasp.webgoat.lesson/auth-bypass@v8.0.0.M15?type=jar represents not only the specific component, tied through the component bom-ref attribute, but also a unique dependency hierarchy within the dependencies section. Given this how can we also represent the following hierarchy within the same aggregate SBOM?

In order to achieve this we need to have some way of enriching the ref attribute value so it represents not only the specific component but also the direct dependencies in its particular location within the dependency graph, for example including a hash which would be derived from each set of dependencies. This hash would need to be calculated from the leaves back to the root, with every deviation in the dependency tree propagating its way up to the root.

We could then have a representation similar to the following

    ref="pkg:maven/org.owasp.webgoat.lesson/auth-bypass@v8.0.0.M15?hash=&type=jar">
  
    ref="pkg:maven/org.owasp.webgoat.lesson/auth-bypass@v8.0.0.M15?hash=&type=jar">

Note: The child dependencies in the example above should also have a hash, however these have been omitted for brevity.

The above would allow us to represent different hierarchies, but now we have another problem. Each reference used in the dependencies section must refer to an existing component within the components section and, therefore, we now need the component to be defined for each reference in use, e.g.

    bom-ref="pkg:maven/org.owasp.webgoat.lesson/auth-bypass@v8.0.0.M15?hash=&type=jar">
  OWASP
  org.owasp.webgoat.lesson
  auth-bypass
  v8.0.0.M15
  Parent Pom for the WebGoat Project. A deliberately insecure Web Application
  pkg:maven/org.owasp.webgoat.lesson/auth-bypass@v8.0.0.M15?type=jar
  ...



    bom-ref="pkg:maven/org.owasp.webgoat.lesson/auth-bypass@v8.0.0.M15?hash=&type=jar">
  OWASP
  org.owasp.webgoat.lesson
  auth-bypass
  v8.0.0.M15
  Parent Pom for the WebGoat Project. A deliberately insecure Web Application
  pkg:maven/org.owasp.webgoat.lesson/auth-bypass@v8.0.0.M15?type=jar
  ...

It is this change which, while not invalid according to the specification schema, will likely cause problems for tools which have made the assumption the component can only exist once.

Conclusions

There is a CycloneDX maven plugin PR open to modify the plugin's behaviour and generate an aggregate SBOM using the above hashing scheme, representing all the dependency hierarchies within a multi-module project. There is also an associated CycloneDX maven plugin issue where the reasons for this change are still being discussed, as well as a number of discussions on how the specification can evolve to address this issue in a cleaner way.

I am hopeful we can come up with a suitable resolution to these discussions and deliver a solution to the issue, however until this is achieved the dependencies section of the aggregate SBOMs generated by the CycloneDX maven plugin is unreliable and should not be trusted. The only reliable source of dependency hierarchy information is to be found within the individual SBOMs of each project.

in-toto attestations

2023-03-13T00:00:00.000Z

When we sign an artifact, like a blob, the signature proves that we were in possesion of the private key. When we verify, we use the signature, the public key, and the blob, and we are verifying that this was in fact the case. But it does not say anything else about the artifact, we don't know what was actually signed.

By providing, and signing a document specifying statements about the artifact we can say things about the artifact as well. Statements could be anything which we will address later in this document. A signed Statement is called an Attestation.

An attestation is authenticated metadata about software artifacts and follows the Software-chain Levels for Software Artifacts attestation model.

An attestation can be json object, and the outer-most element is the Envelope:

{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "",
  "signatures": [{ "sig": "" }]
}

Notice that the payload is a base64 encoded Statement. This format follows the DSSE format.

The payloadType could be JSON, CBOR, or ProtoBuf.

The structure of the Statement, in payload element above, looks something like this (before it is base64 encoded):

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [
    {
      "name": "",
      "digest": { "": "" }
    }
  ],
  "predicateType": "",
  "predicate": {}
}

The subjects bind this attestation to a set of software artifacts, notice that this is an array of objects.

Each software artifact is given a name and a digest. The digest contains the name of the hashing algorithm used, and the digest (the outcome of the hash function). The name could be a file name but it can also be left unspecified using _.

This leads us to the predicate fields, which like shown above has one field for the type of the predicate (predicateType), and an object as the content of the predicate.

The predicate can contain pretty much any metadata related to the Statement object's subjects. The predicateType provides a way of knowing how to interpret the predicate field.

Examples of predicate types are SLSA Provenance, in-toto Link , SPDX , Software Supply Chain Attribute Integrity (SCAI).

NPM also uses this for it to publish attestations:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [
    {
      "name": "pkg:npm/@scope/package-foo@1.4.3",
      "digest": { "sha512": "41o0P/CEffYGDqvo2pHQXRBOfFOxvYY3WkwkQTy..." }
    }
  ],
  "predicateType": "https://github.com/npm/attestation/tree/main/specs/publish/v0.1",
  "predicate": {
    "name": "@scope/package-foo",
    "version": "1.4.3",
    "registry": "https://registry.npmjs.org"
  }
}

The digest in this case is the sha512sum of the published tar file.

So, we mentioned that the predicate type is used by the consumer of the predicate so it knows how to interpret the contents of the predicate. But who is the consumer?
Most often this would be a Policy Engine. The Policy engine would be passed the contents of the Statement related to the predicate, and rules written in the Policy Engine's language would process the predicate as input. The outcome would be a true/false result (remember that a predicate is a statement/function that returns true or false).

To try to make this a little more concrete lets take a look at an example that creates an attestation.

For this example I'm going to use a GitHub Action named slsa-github-generator which can generate SLSA provenance attestations for github native projects. This generator can generate SLSA provenance for SLSA level 3.

The example project I'm going to use is tuf-keyid but the actual project is not important in this case, any Rust project could have been used.

So we need to set up a GitHub Action which can been seen in provenance.yaml.

After that workflow has run it will produce an attestation and a binary which we will use to verify.

First, we need to download the binary from the workflow run (we should really be able to be download this from the releases page too, but I've not been able to get that to work just yet):

$ unzip tuf-keyid.zip
$ file tuf-keyid
tuf-keyid: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ceaa62d49b024798ebd7fe7d021f3ade5925b1f9, for GNU/Linux 3.2.0, with debug_info, not stripped

And then we need to download the attestation file:

$ curl -L https://github.com/danbev/tuf-keyid/releases/download/v0.2.0/tuf-keyid.intoto.jsonl --output tuf-keyid.intoto.jsonl

Lets inspect the attestation file:

$ cat tuf-keyid.intoto.jsonl | jq
{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "...",
  "signatures": [
    {
      "keyid": "",
      "sig": "MEUCIHwmJopmrXWqi+rKIeTlWW0r027hLL1nO7xEj0mW8czsAiEAhdc6SDlhWo3m0YOtsUSoIYSlvw3Xu7ts3S8btHzdMpw=",
      "cert": "-----BEGIN CERTIFICATE-----\nMIIDtjCCAzygAwIBAgIUCeak2sfkfZbS0IMRSbK4+BHcUzAwCgYIKoZIzj0EAwMw\nNzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl\ncm1lZGlhdGUwHhcNMjMwMTI2MTAxMzQxWhcNMjMwMTI2MTAyMzQxWjAAMFkwEwYH\nKoZIzj0CAQYIKoZIzj0DAQcDQgAEZMurC3H80wzo+Xn7uifeTDV/AAFnye8uFwEj\n5VmxJb30VzuEw8gD8/Dj4V79bIW9sePcZjvREhFWak+PhUZVMqOCAlswggJXMA4G\nA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUncOT\nSyRyKgylBYlUHwPF+EyemfkwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4Y\nZD8wgYQGA1UdEQEB/wR6MHiGdmh0dHBzOi8vZ2l0aHViLmNvbS9zbHNhLWZyYW1l\nd29yay9zbHNhLWdpdGh1Yi1nZW5lcmF0b3IvLmdpdGh1Yi93b3JrZmxvd3MvZ2Vu\nZXJhdG9yX2dlbmVyaWNfc2xzYTMueW1sQHJlZnMvdGFncy92MS40LjAwOQYKKwYB\nBAGDvzABAQQraHR0cHM6Ly90b2tlbi5hY3Rpb25zLmdpdGh1YnVzZXJjb250ZW50\nLmNvbTASBgorBgEEAYO/MAECBARwdXNoMDYGCisGAQQBg78wAQMEKDUxM2IwZTA2\nMGM3NmExZGVkN2IxYTQxNzMxNjUxMDM4MzhmOGRkZTcwFQYKKwYBBAGDvzABBAQH\nUHVibGlzaDAeBgorBgEEAYO/MAEFBBBkYW5iZXYvdHVmLWtleWlkMB4GCisGAQQB\ng78wAQYEEHJlZnMvdGFncy92MC4yLjAwgYoGCisGAQQB1nkCBAIEfAR6AHgAdgDd\nPTBqxscRMmMZHhyZZzcCokpeuN48rf+HinKALynujgAAAYXtkZ+vAAAEAwBHMEUC\nIQDgO+S94sXq3wcfg344IV8FRhynvsJsVFEfHmwOHGqAVgIgArfX+7pnaLrplJ0u\nXB6tlWaCxQJ7GAo9YByqXCa0b2gwCgYIKoZIzj0EAwMDaAAwZQIxAOYkXbpLbSqC\njdORW6lWGWB/Ts2aOhK7VAHaQCRgRHQGiZx4Pe/LCwqkQF/1W2BAEQIwLB9Ic2jt\nIiEjtw8xKFDQAfnUleNUtZ51LXgXEkdpIX9cnj4UdR6k4gu/wul16Bd8\n-----END CERTIFICATE-----\n"
    }
  ]
}

If we look back at the beginning of this document we will see that this format matches the Envelope of the attestation, and we have the payloadType, a payload, and signatures.

The certificate can be inspected using:

$ cat tuf-keyid.intoto.jsonl | jq -r '.signatures[].cert' | openssl x509 --text

Recall that the payload is a base64 encoded Statement. Let's decode the Statement and take a closer a look at it:

$ cat tuf-keyid.intoto.jsonl | jq -r '.payload' | base64 -d | jq
{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "tuf-keyid",
      "digest": {
        "sha256": "470c549740f98fe1b1977d48e014031ed5183785fd459df7e04605daefe8e293"
      }
    }
  ],
  "predicate": {
    "builder": {
      "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.4.0"
    },
    "buildType": "https://github.com/slsa-framework/slsa-github-generator/generic@v1",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/danbev/tuf-keyid@refs/tags/v0.2.0",
        "digest": {
          "sha1": "513b0e060c76a1ded7b1a4173165103838f8dde7"
        },
        "entryPoint": ".github/workflows/provenance.yaml"
      },
      "parameters": {},
      "environment": {
        "github_actor": "danbev",
        "github_actor_id": "432351",
        "github_base_ref": "",
        "github_event_name": "push",
        "github_event_payload": {
          "after": "13c69c54cbd04d1920cc5e42441f0a693a371494",
          "base_ref": null,
          "before": "0000000000000000000000000000000000000000",
          "commits": [],
          "compare": "https://github.com/danbev/tuf-keyid/compare/v0.2.0",
          "created": true,
          "deleted": false,
          "forced": false,
          "head_commit": {
            "author": {
              "email": "daniel.bevenius@gmail.com",
              "name": "Daniel Bevenius",
              "username": "danbev"
            },
            "committer": {
              "email": "daniel.bevenius@gmail.com",
              "name": "Daniel Bevenius",
              "username": "danbev"
            },
            "distinct": true,
            "id": "513b0e060c76a1ded7b1a4173165103838f8dde7",
            "message": "Add content(releases) write permission\n\nSigned-off-by: Daniel Bevenius ",
            "timestamp": "2023-01-26T11:09:02+01:00",
            "tree_id": "5030177fa47fc8b8252c26e8556083b4abc5df71",
            "url": "https://github.com/danbev/tuf-keyid/commit/513b0e060c76a1ded7b1a4173165103838f8dde7"
          },
          "pusher": {
            "email": "daniel.bevenius@gmail.com",
            "name": "danbev"
          },
          "ref": "refs/tags/v0.2.0",
          "repository": {
            "allow_forking": true,
            "archive_url": "https://api.github.com/repos/danbev/tuf-keyid/{archive_format}{/ref}",
            "archived": false,
            "assignees_url": "https://api.github.com/repos/danbev/tuf-keyid/assignees{/user}",
            "blobs_url": "https://api.github.com/repos/danbev/tuf-keyid/git/blobs{/sha}",
            "branches_url": "https://api.github.com/repos/danbev/tuf-keyid/branches{/branch}",
            "clone_url": "https://github.com/danbev/tuf-keyid.git",
            "collaborators_url": "https://api.github.com/repos/danbev/tuf-keyid/collaborators{/collaborator}",
            "comments_url": "https://api.github.com/repos/danbev/tuf-keyid/comments{/number}",
            "commits_url": "https://api.github.com/repos/danbev/tuf-keyid/commits{/sha}",
            "compare_url": "https://api.github.com/repos/danbev/tuf-keyid/compare/{base}...{head}",
            "contents_url": "https://api.github.com/repos/danbev/tuf-keyid/contents/{+path}",
            "contributors_url": "https://api.github.com/repos/danbev/tuf-keyid/contributors",
            "created_at": 1674117641,
            "default_branch": "main",
            "deployments_url": "https://api.github.com/repos/danbev/tuf-keyid/deployments",
            "description": "A command line tool to print the key id for a TUF public key in JSON format.",
            "disabled": false,
            "downloads_url": "https://api.github.com/repos/danbev/tuf-keyid/downloads",
            "events_url": "https://api.github.com/repos/danbev/tuf-keyid/events",
            "fork": false,
            "forks": 0,
            "forks_count": 0,
            "forks_url": "https://api.github.com/repos/danbev/tuf-keyid/forks",
            "full_name": "danbev/tuf-keyid",
            "git_commits_url": "https://api.github.com/repos/danbev/tuf-keyid/git/commits{/sha}",
            "git_refs_url": "https://api.github.com/repos/danbev/tuf-keyid/git/refs{/sha}",
            "git_tags_url": "https://api.github.com/repos/danbev/tuf-keyid/git/tags{/sha}",
            "git_url": "git://github.com/danbev/tuf-keyid.git",
            "has_discussions": false,
            "has_downloads": true,
            "has_issues": true,
            "has_pages": false,
            "has_projects": true,
            "has_wiki": true,
            "homepage": null,
            "hooks_url": "https://api.github.com/repos/danbev/tuf-keyid/hooks",
            "html_url": "https://github.com/danbev/tuf-keyid",
            "id": 590801502,
            "is_template": false,
            "issue_comment_url": "https://api.github.com/repos/danbev/tuf-keyid/issues/comments{/number}",
            "issue_events_url": "https://api.github.com/repos/danbev/tuf-keyid/issues/events{/number}",
            "issues_url": "https://api.github.com/repos/danbev/tuf-keyid/issues{/number}",
            "keys_url": "https://api.github.com/repos/danbev/tuf-keyid/keys{/key_id}",
            "labels_url": "https://api.github.com/repos/danbev/tuf-keyid/labels{/name}",
            "language": "Rust",
            "languages_url": "https://api.github.com/repos/danbev/tuf-keyid/languages",
            "license": null,
            "master_branch": "main",
            "merges_url": "https://api.github.com/repos/danbev/tuf-keyid/merges",
            "milestones_url": "https://api.github.com/repos/danbev/tuf-keyid/milestones{/number}",
            "mirror_url": null,
            "name": "tuf-keyid",
            "node_id": "R_kgDOIzbqXg",
            "notifications_url": "https://api.github.com/repos/danbev/tuf-keyid/notifications{?since,all,participating}",
            "open_issues": 0,
            "open_issues_count": 0,
            "owner": {
              "avatar_url": "https://avatars.githubusercontent.com/u/432351?v=4",
              "email": "daniel.bevenius@gmail.com",
              "events_url": "https://api.github.com/users/danbev/events{/privacy}",
              "followers_url": "https://api.github.com/users/danbev/followers",
              "following_url": "https://api.github.com/users/danbev/following{/other_user}",
              "gists_url": "https://api.github.com/users/danbev/gists{/gist_id}",
              "gravatar_id": "",
              "html_url": "https://github.com/danbev",
              "id": 432351,
              "login": "danbev",
              "name": "danbev",
              "node_id": "MDQ6VXNlcjQzMjM1MQ==",
              "organizations_url": "https://api.github.com/users/danbev/orgs",
              "received_events_url": "https://api.github.com/users/danbev/received_events",
              "repos_url": "https://api.github.com/users/danbev/repos",
              "site_admin": false,
              "starred_url": "https://api.github.com/users/danbev/starred{/owner}{/repo}",
              "subscriptions_url": "https://api.github.com/users/danbev/subscriptions",
              "type": "User",
              "url": "https://api.github.com/users/danbev"
            },
            "private": false,
            "pulls_url": "https://api.github.com/repos/danbev/tuf-keyid/pulls{/number}",
            "pushed_at": 1674727856,
            "releases_url": "https://api.github.com/repos/danbev/tuf-keyid/releases{/id}",
            "size": 21,
            "ssh_url": "git@github.com:danbev/tuf-keyid.git",
            "stargazers": 1,
            "stargazers_count": 1,
            "stargazers_url": "https://api.github.com/repos/danbev/tuf-keyid/stargazers",
            "statuses_url": "https://api.github.com/repos/danbev/tuf-keyid/statuses/{sha}",
            "subscribers_url": "https://api.github.com/repos/danbev/tuf-keyid/subscribers",
            "subscription_url": "https://api.github.com/repos/danbev/tuf-keyid/subscription",
            "svn_url": "https://github.com/danbev/tuf-keyid",
            "tags_url": "https://api.github.com/repos/danbev/tuf-keyid/tags",
            "teams_url": "https://api.github.com/repos/danbev/tuf-keyid/teams",
            "topics": [],
            "trees_url": "https://api.github.com/repos/danbev/tuf-keyid/git/trees{/sha}",
            "updated_at": "2023-01-19T10:26:19Z",
            "url": "https://github.com/danbev/tuf-keyid",
            "visibility": "public",
            "watchers": 1,
            "watchers_count": 1,
            "web_commit_signoff_required": false
          },
          "sender": {
            "avatar_url": "https://avatars.githubusercontent.com/u/432351?v=4",
            "events_url": "https://api.github.com/users/danbev/events{/privacy}",
            "followers_url": "https://api.github.com/users/danbev/followers",
            "following_url": "https://api.github.com/users/danbev/following{/other_user}",
            "gists_url": "https://api.github.com/users/danbev/gists{/gist_id}",
            "gravatar_id": "",
            "html_url": "https://github.com/danbev",
            "id": 432351,
            "login": "danbev",
            "node_id": "MDQ6VXNlcjQzMjM1MQ==",
            "organizations_url": "https://api.github.com/users/danbev/orgs",
            "received_events_url": "https://api.github.com/users/danbev/received_events",
            "repos_url": "https://api.github.com/users/danbev/repos",
            "site_admin": false,
            "starred_url": "https://api.github.com/users/danbev/starred{/owner}{/repo}",
            "subscriptions_url": "https://api.github.com/users/danbev/subscriptions",
            "type": "User",
            "url": "https://api.github.com/users/danbev"
          }
        },
        "github_head_ref": "",
        "github_ref": "refs/tags/v0.2.0",
        "github_ref_type": "tag",
        "github_repository_id": "590801502",
        "github_repository_owner": "danbev",
        "github_repository_owner_id": "432351",
        "github_run_attempt": "1",
        "github_run_id": "4014167952",
        "github_run_number": "13",
        "github_sha1": "513b0e060c76a1ded7b1a4173165103838f8dde7"
      }
    },
    "metadata": {
      "buildInvocationID": "4014167952-1",
      "completeness": {
        "parameters": true,
        "environment": false,
        "materials": false
      },
      "reproducible": false
    },
    "materials": [
      {
        "uri": "git+https://github.com/danbev/tuf-keyid@refs/tags/v0.2.0",
        "digest": {
          "sha1": "513b0e060c76a1ded7b1a4173165103838f8dde7"
        }
      }
    ]
  }
}

So that gives us a concrete example of an attestation and in this case it is a SLSA Provenance.

Notice that the digest in the subject array is the sha256sum of the tuf-keyid binary:

$ cat tuf-keyid.intoto.jsonl | jq -r '.payload' | base64 -d | jq -r '.subject[].digest.sha256'
470c549740f98fe1b1977d48e014031ed5183785fd459df7e04605daefe8e293
$ sha256sum tuf-keyid
470c549740f98fe1b1977d48e014031ed5183785fd459df7e04605daefe8e293  tuf-keyid

Alright, so next step if to verify the binary that we produced, using the attestation.

There is project named slsa-verifier which can be used to verify the artifact. Installing slsa-verifier:

$ go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@v2.0.1

Let's try verifying the attestation using slsa-verifier and using a local build of the binary, that is, a local build on my laptop:

$ slsa-verifier verify-artifact --provenance-path tuf-keyid.intoto.jsonl \
  --source-uri github.com/danbev/tuf-keyid \
   ~/work/rust/tuf-keyid/target/release/tuf-keyid
Verified signature against tlog entry index 11978552 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77a217b8f07bccab3dc8caa1c7badf65f104a762647e5e355db23ccc13a22e275dd
FAILED: SLSA verification failed: expected hash '32dcff46ec4be5462a66aeb5d82366da3b870d36796f3d1fe6fec6245f21ce6f' not found: artifact hash does not match provenance subject

And now let's see what happens when we try with the binary that was produced by the GitHub action:

$ slsa-verifier verify-artifact --provenance-path tuf-keyid.intoto.jsonl \
  --source-uri github.com/danbev/tuf-keyid \
   tuf-keyid
Verified signature against tlog entry index 11978552 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77a217b8f07bccab3dc8caa1c7badf65f104a762647e5e355db23ccc13a22e275dd
Verified build using builder https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.4.0 at commit 513b0e060c76a1ded7b1a4173165103838f8dde7
PASSED: Verified SLSA provenance

slsa-verifier can also print out the predicate information after validation , using --print-provenance, which could then be passed to a Policy Engine:

$ slsa-verifier verify-artifact --provenance-path tuf-keyid.intoto.jsonl \
  --source-uri github.com/danbev/tuf-keyid \
  --print-provenance \
  tuf-keyid

Signing elf binaries, or not?! Lessons learned.

2023-02-13T00:00:00.000Z

Trying to figure out what went into a binary can be a tricky thing. And once you figured it out, how do you transport this information? True, it all starts simple: Java, NodeJS, Go, or Rust, all languages¹ bring their dependency management, which defines what the final command line tool you create is made of. Or, does it?

But let's take a step back: A typical use-case today is to download a command line application from the internet. Take helm for example. You navigate to their GitHub releases page, download the binary, unzip it into a local folder and run it. But, what exactly is inside the binary?

SBOMs

Software Bills of Material (SBOMs) are a thing which already exist. Yet, someone needs to create them, and creating an accurate SBOM can be tricky.

There are tools to create SBOMs from the source code of a project, but that doesn't tell the whole story in most cases. Those tools simply analyze the dependency information declared in e.g. a package.lock file, or a Maven pom.xml. Should be enough, right? Well, no. Maven projects for example have "profiles", and you need to exactly generate the SBOM for the profile that gets enabled when creating the final artifact. Also, with Maven mirrors and proxies, it's not always 100% clear what gets into a "binary" and where it comes from.

What really goes in

Then again, JAR files aren't real binaries are they. They are ZIP files, which contain compiled .class files. So it actually is pretty simple to understand what is in there. Assuming you trust your build process (which is a topic of its own). Even if you create a "fat", or "shaded" JAR, it is possible to understand what really ended up in your "binary".

And, others can do the same. Rust for example allows one use cargo auditable, to tap into the compilation process, and record the actual dependencies which go into a binary. On Linux, the binary will be an ELF file, which then contains the dependency information from the compilation process. And Go can do the same.

Null and void

But, if someone can write dependency information into a binary, then someone else can also overwrite it. So unless you protect the binary against modifications, this information isn't really trustworthy. Taking a look at the Helm release page, you will find SHA based checksums. Isn't that enough?

No, not really. Because if someone can alter the binary on the download page, the attacker can also swap out the SHA checksum file. The checksum, or digest, really isn't more than a checksum. By its own, it doesn't protect much.

If however, you encrypt the digest with a private key that only the author knows, and you publish the public key part, then this becomes a "signature". And this is good enough to prove, that only the person how knew the private key, could have signed the binary. And if we can trust this person to create the correct SBOM and binary, and keep the private key secure, we are good.

Usability

Or, not! In the Maven world JARs have been signed for quite a while. Everyone uploading JARs to Maven Central needs to sign their JAR with GPG. And I guess most people never validated a JAR during a build.

On the other side, the Eclipse IDE (as well as some other Java applications), did JAR file validation for quite a while. Whenever you install a plugin, it cryptographically validates the JAR. And it's easy, as the JAR file itself is signed, and the signature is part of the JAR file. As part of the build process in the Eclipse Foundation build system, JARs which got created by the build, can automatically get signed. No additional files needed, and only the actual build output is considered, no guessing of dependencies.

From a user perspective, the IDE automatically checks signatures, and only bothers the user if an issue was found. The user can override, because the idea is to give the final authority to the user.

Back to binaries

Now, just assume we could do the same with (ELF) binaries. In fact this was possible a while back, Solaris had some tools to sign ELF binaries. That doesn't help on modern Linux systems. But with a bit of Rust code, it was possible to create elfsign. The idea is simple:

Create a digest of all relevant ELF sections and headers
Sign this digest
Add the signature to the ELF binary as a new section

Solvable downsides

The first downside might be that people are afraid of signed binaries. Windows and macOS have been doing this for a while, and it happens that signatures get in the way of the user running a binary. Well, actually it is the operating system which gets into the user's way. To protect the user, that's the argument. And that might be true, but it also is true that some users indeed know better than the operating system and want to have the final word in what they can run.

This problem can easily be addressed. Checking a signature, and making a decision if a binary can be run or not, actually are two different things. Even if a system brings a default rule/policy set which would reject invalid signatures, it could still be possible to let the user customize the behavior and override, just like the Eclipse IDE does.

Another issue the handling of keys and certificates. Prices for code signing certificates can be quite high. Especially when we are talking about open source projects, this can become a truly limiting factor. It also takes a bit of care, handling a private key properly.

Luckily, we now have sigstore. Sigstore can help us with two things, creating short-lived private keys (Fulcio), and a tamper-resistant log (Rekor). We already talked a bit about both in the context of [gitsign]({% post_url 2022-12-02-sign-commits-with-sigstore %}).

Adding Fulcio and Rekor to elfsign, we gain a bunch of cool things:

Short-lived, disposable private keys: You don't need to store them, they are only valid for a few minutes.
X.509 certificates: Alongside the key, we get an X.509 certificates, with our identity, which we can use for signing.
An attestation that we provided the valid certificate and signature to Rekor, at a time the key was valid

And with that, we can easily implement elfsign sign to sign a binary, and elfsign verify to validate one. We could also create something like elfsign execute to verify and execute, but that's just a variant of verify.

As we can prove, using Rekor, that we did own the private key during the time the certificate was valid, and we provided the signature/digest at the same time, we now only need to decide if we want to trust the issuer and the subject the certificate was issued for. And by storing [the Rekor bundle]({% post_url 2023-01-13-sigstore-bundle-format %}), we can do this offline too.

Too good to be true?

So where's the catch?

Signing elf binaries adds a bit of extra complexity. Creating a digest of an ELF binary isn't as trivial as just running sha256sum on a file. Storing an additional "signature section" in the ELF binary, will actually alter it. So it is necessary have a normalized view on the ELF binary, which creates a reproducible digest, one that does include all important information, but excludes the signature information itself, and still is a valid ELF binary format.

It works, but is a bit complex. And more complexity might lead to more bugs, which isn't a good thing when it comes to cryptography. But if this allows one to drop handling additional files (like SBOMs or checksum files), and increase the usability, it may actually be worth it.

The problem is, that the tooling which creates the dependency information for the ELF binaries, isn't accurate enough.

In many cases it works, but as soon as you include a C library, add some JavaScript for an embedded frontend, or deviate from "standard artifact repositories", many of those tools just fall short. And I am not even talking about all those little hacks in build systems, or the mess called "vendor" folder in Go.

SBOM formats like CycloneDX allow you to compensate and fix up generated SBOMs. But, that's another step in the build process, and the output doesn't go into the ELF binary. As Go only cares about Go dependencies, and Cargo only about Cargo.

So adding all the complexity isn't good enough in the end. You still need to handle an extra file, and validate it.

Happy end?

The truth is, cosign, which is intended to sign containers, can actually sign any BLOB. Just the same way, using Fulcio to get a short-lived private key and certificate, and storing the signature in Rekor. So if we can make our peace with handling an extra file, we can just use cosign sign-blob and cosign verify-blob to sign anything we want. Using cosign attest-blob, we can even "attach" an SBOM to the Rekor log entry.

Yes, we need to handle the extra "bundle" and "signature" files. Or we can accept the fact that we need rely on the uptime of the Rekor instance (or our ISP). But it definitely improves the situation over the status quo.

So what?

elfsign was a nice experiment. And while it didn't work out, I still learned a lot. I also still believe that the idea works out in general. It just needs more work for a more specialized solution. So the approach of "cosign blob" is a more generic one. However, through that, also less user-friendly one.

But this situation could also be improved. Just assume someone would create a more convenient version of cosign, which "downloads and verifies" or "verifies and executes". That would definitely lead to a similar user experience, and help with adoption.

And, having a policy engine like Seedwing, you could actually define checks like: Only run this binary if it is signed, and does not contain a dependency which has an active CVE.

If you are interested in things like this, maybe this blog post gave you a few insights and ideas.

Yes, C/C++ is missing here. Let's not talk about build systems and dependency management for C/C++ 😉 ↩

Continuing the Adventure with the CycloneDX Maven Plugin

2023-02-10T00:00:00.000Z

My investigation into the CycloneDX Maven Plugin began back in November/December 2022 with the intent of integrating the plugin into the Quarkus build process to generate Software Bill of Materials (SBOMs) for the project. I quickly discovered issues in the plugin and raised these with the maintainer early in December, writing a blog post (An Adventure with the CycloneDX Maven Plugin) to help clarify each issue. I finally opened a pull request in early January to move the conversation forward and this is where our story continues .....

Two weeks ago I received some feedback on the pull request from Steve Springett, he ran my version of the CycloneDX plugin and hit some problems. Steve was running the plugin against the WebGoat 8.0.0 codebase and noticed some dependencies were not present in the components section! This was intriguing as I had been running the plugin against a complex codebase (Quarkus) without seeing the issue, and had also included a BOM validation step in my pull request which would emit WARNING log messages if this situation occurred. I took a look at the WebGoat codebase and could not get this specific version to build, however a build of a different version did succeed without displaying the problem. Curiouser and curiouser .......

We now jump forward to this Monday (4 days ago) when I'm trying to arrange a call with Steve to discuss the differences in our environments and help move this forward. Steve suggested we include Hervé Boutemy in the call, the new maintainer of the upstream codebase, however he offered instead to review my pull request as-is. It's at this point I realised the pull request now had conflicts with the base branch, so I quickly rebased and fixed the conflicts. I also decided to give the WebGoat codebase another try.

I spent time investigating the failures I had seen with the WebGoat build and eventually realised I needed to be running on an older version of Java, I needed to install JDK8 in order to make progress. I was now able to build the same version of the code Steve had been using, although with errors, but could now see missing components. Even better, I could also see the expected WARNING messages were present!

[WARNING] CycloneDX: Dependency missing component entry: pkg:maven/org.webjars/jquery@1.11.1?type=jar
[WARNING] CycloneDX: Dependency missing component entry: pkg:maven/commons-io/commons-io@LATEST?type=jar
[WARNING] CycloneDX: Dependency missing component entry: pkg:maven/com.google.guava/guava@18.0?type=jar
[WARNING] CycloneDX: Dependency missing component entry: pkg:maven/org.apache.commons/commons-lang3@3.4?type=jar

This was great, I now had something to work with.

Comparing Upstream Output with my pull request

Before investigating I decided to first understand the differences in output between the current upstream codebase and what was being generated by my pull request. This may provide some insight into the new issue and could possibly hint at a direction to follow.

With regard to components I discovered three were missing from my version of the bom, however in each case the component was never referenced in the dependencies section. These components were

pkg:maven/com.google.guava/guava@20.0?type=jar
pkg:maven/commons-io/commons-io@2.11.0?type=jar
pkg:maven/org.apache.commons/commons-lang3@3.6?type=jar

These are three of the components we were warned about, but suspiciously each has a different version.

I also found we were now including two additional components, these are

pkg:maven/junit/junit@4.12?type=jar
pkg:maven/org.hamcrest/hamcrest-core@1.3?type=jar

With regard to dependencies we were expanding the dependency tree to include transitive dependencies for the following

pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.8.11.1?type=jar
pkg:maven/org.springframework.boot/spring-boot-autoconfigure@1.5.12.RELEASE?type=jar
pkg:maven/org.springframework.boot/spring-boot@1.5.12.RELEASE?type=jar
pkg:maven/org.springframework.security/spring-security-core@4.2.5.RELEASE?type=jar
pkg:maven/org.springframework.security/spring-security-web@4.2.5.RELEASE?type=jar
pkg:maven/org.springframework/spring-aop@4.3.16.RELEASE?type=jar
pkg:maven/org.springframework/spring-beans@4.3.16.RELEASE?type=jar
pkg:maven/org.springframework/spring-context@4.3.16.RELEASE?type=jar
pkg:maven/org.springframework/spring-expression@4.3.16.RELEASE?type=jar
pkg:maven/org.springframework/spring-test@4.3.16.RELEASE?type=jar
pkg:maven/org.springframework/spring-web@4.3.16.RELEASE?type=jar
pkg:maven/org.webjars/bootstrap@3.3.7?type=jar

as well as adding new dependencies into the tree

pkg:maven/aopalliance/aopalliance@1.0?type=jar
pkg:maven/org.hamcrest/hamcrest-core@1.3?type=jar
pkg:maven/junit/junit@4.12?type=jar

however, we are also seeing the following dependencies without any mention in the component section

pkg:maven/com.google.guava/guava@18.0?type=jar
pkg:maven/commons-io/commons-io@LATEST?type=jar
pkg:maven/org.apache.commons/commons-lang3@3.4?type=jar
pkg:maven/org.webjars/jquery@1.11.1?type=jar

These match the list of dependencies reported as WARNINGs in the log, confirming the issue.

We now know the pull request codebase is having a beneficial effect and providing a more detailed dependency graph. What is left to work out is why we are seeing these four dependencies in the tree with no associated component.

Identity, Does it Matter?

Before we take a look at each of the problematic dependencies let us quickly cover how components are identified in the upstream CycloneDX codebase and in my pull request.

The upstream codebase discovers its components by asking maven for those artifacts which it has resolved to be the definitive set for the build. These artifacts are then filtered based on their scope, however as we discovered in the previous post this does not follow the transitive scoping rules applied by maven, and then used to create the set of components included in the bom file. It is also important to realise that when resolving the dependency tree the upstream codebase will not include any dependencies which do not exist in the set of known components. No components will be removed, even if they do not take part in the dependency tree.

In my pull request we take a slightly different approach. To discover the set of possible components we still ask maven for the definitive set of artifacts, but rely instead on maven to handle the filtering when collecting the dependency graph. At the end of the process we check the set of components and remove any which do not appear in the dependency tree. No dependencies will be removed, even if they do not have an associated component, however a warning is emitted on the console. This is the warning we are now seeing.

These approaches are, essentially, tackling the discovery from opposite directions.

With the above in mind let us now take a look at the problematic artifacts and return to our trusty dependency tree graph. We can see from the WARNINGs that we should focus on two of the projects

xxe for guava and commons-lang3
webwolf for jquery and commons-io

A look at Guava

The parts of the xxe dependency tree which are of interest are

org.owasp.webgoat.lesson:xxe:jar:v8.0.0.M15
+- com.github.tomakehurst:wiremock:jar:2.8.0:test
|  +- com.google.guava:guava:jar:20.0:provided
|  +- com.flipkart.zjsonpatch:zjsonpatch:jar:0.3.0:test
|  |  +- (com.google.guava:guava:jar:18.0:test - omitted for conflict with 20.0)
+- org.owasp.webgoat:webgoat-container:jar:v8.0.0.M15:provided
|  +- (com.google.guava:guava:jar:18.0:provided - omitted for conflict with 20.0)
+- org.owasp.webgoat:webgoat-container:jar:tests:v8.0.0.M15:test
|  +- (com.google.guava:guava:jar:18.0:test - omitted for conflict with 20.0)

From this we can see guava:20.0 has been resolved as the winner by maven, however the winning artifact is hidden beneath a test scoped artifact (we saw this in our previous issues). We can also see the artifact discovered through the transitive compile scope is being reported as guava:18.0, so while version 20.0 has been declared the winner we are still seeing the marker nodes report the original version of 18.0. How does each version of the plugin handle this scenario?

The upstream code discovers guava:20.0 in the set of resolved artifacts, including it in its set of known components. When creating the dependency tree it discovers guava:18.0, however decides not to include it as this version is not in the set of known components. This results in a bom which includes the guava:20.0 component and a dependency graph which does not reference the guava dependency, losing the dependency relationship between webgoat-container and guava. The bom looks as follows

In my pull request we discover guava:20.0 in the set of resolved artifacts, including it as a known component. When creating the dependency tree we discover the guava:18.0 dependency and include it in the tree. At the end of the process we drop components which are not mentioned in the dependency tree, in this instance the guava:20.0 component, but keep the dependency relationship between webgoat-container and guava:18.0, which is a missing component. The bom looks as follows

A look at commons-lang3

The parts of the xxe dependency tree which are of interest are

org.owasp.webgoat.lesson:xxe:jar:v8.0.0.M15
+- com.github.tomakehurst:wiremock:jar:2.8.0:test
|  +- org.apache.commons:commons-lang3:jar:3.6:provided
|  \- com.github.jknack:handlebars:jar:4.0.6:test
|     +- (org.apache.commons:commons-lang3:jar:3.1:test - omitted for conflict with 3.6)
+- org.owasp.webgoat:webgoat-container:jar:v8.0.0.M15:provided
|  +- (org.apache.commons:commons-lang3:jar:3.4:provided - omitted for conflict with 3.6)
+- org.owasp.webgoat:webgoat-container:jar:tests:v8.0.0.M15:test
|  +- (org.apache.commons:commons-lang3:jar:3.4:test - omitted for conflict with 3.6)

We can see from the above that the commons-lang3 artifact suffers from the same problem as the guava artifact, with the artifact identified through the transitive compile scope having a version of 3.4 while the resolved winner has a version of 3.6 but is hidden beneath a test scoped artifact. We can also see there is a third version being referenced beneath the test scoped artifact, commons-lang3:3.1.

The upstream bom looks as follows

The bom from my pull request looks as follows

A look at jquery

The parts of the webwolf dependency tree which are of interest are

org.owasp.webgoat:webwolf:jar:v8.0.0.M15
+- org.webjars:bootstrap:jar:3.3.7:compile
|  \- (org.webjars:jquery:jar:1.11.1:compile - omitted for conflict with 3.2.1)
+- org.webjars:jquery:jar:3.2.1:compile

This scenario is slightly different from the previous ones in that the resolved component is not hidden behind a test scoped artifact. We can see from the above that we have two artifacts being discovered within the transitive compile scope, jquery:3.2.1 and jquery:1.11.1. Version 3.2.1 is the resolved winner and version 1.11.1 is the marker node for an artifact which lost the resolution process. How does each version of the plugin handle this scenario?

The upstream code discovers jquery:3.2.1 in the set of resolved artifacts, including it in its set of known components. When creating the dependency tree it discovers both jquery:3.2.1 and jquery:1.11.1, including 3.2.1 in the tree but deciding not to include 1.11.1 as this does not match a known component. This results in a bom which includes the jquery:3.2.1 component and the dependency relationship between webwolf and jquery but loses the dependency relationship between bootstrap and jquery. The bom looks as follows

In my pull request we discover jquery:3.2.1 in the set of resolved artifacts, including it as a known component. When creating the dependency tree we discover both jquery:3.2.1 and jquery:1.11.1, including both in the tree. This results in a bom which includes the jquery:3.2.1 component and the dependency relationship between webwolf and jquery. The bom also keeps the dependency relationship between bootstrap and jquery:1.11.1, which is a missing component. The bom looks as follows

A look at commons-io

The parts of the webwolf dependency tree which are of interest are

org.owasp.webgoat:webwolf:jar:v8.0.0.M15
+- commons-io:commons-io:jar:LATEST:compile

Now this scenario is very different from the previous ones. In each of the previous scenarios the dependency tree included marker nodes with versions which did not match the version resolved by maven, the first two with the resolved artifact hidden behind a test scoped artifact and the third with both artifacts discovered through the transitive compile scope. So what is going on here? It's time for a quick dive under the covers of maven!

Maven includes support for two metaversions which can be used when specifying the version of an artifact, these are RELEASE and LATEST. These metaversions have specific meanings when resolving artifacts within a pom, these are

RELEASE: represents the latest non-snapshot version of the artifact within a repository
LATEST: represents the latest version of the artifact within a repository, which includes both released and snapshot versions

Note: Using either RELEASE or LATEST in a build breaks reproducibility. Thankfully maven is now issuing the following deprecation WARNING when encountering these metaversions, which means support for these versions should be removed at some point in the future.

[WARNING] 'dependencies.dependency.version' for commons-io:commons-io:jar is either LATEST or RELEASE (both of them are being deprecated)

When maven encounters either of these metaversions it will resolve the artifact to a specific version based on the above meanings. In our case, at least as of today, maven will resolve commons-io:LATEST to commons-io:2.11.0. How does each version of the plugin handle this scenario?

The upstream code discovers commons-io:2.11.0 in the set of resolved artifacts, including it in its set of known components. When creating the dependency tree it discovers commons-io:LATEST, however decides not to include it as this version is not in the set of known components. This results in a bom which includes the commons-io:2.11.0 component and a dependency graph which does not reference the common-io dependency, losing the dependency relationship between webwolf and commons-io. The bom looks as follows

In my pull request we discover commons-io:2.11.0 in the set of resolved artifacts, including it as a known component. When creating the dependency tree we discover the commons-io:LATEST dependency and include it in the tree. At the end of the process we drop components which are not mentioned in the dependency tree, in this instance the commons-io:2.11.0 component, but keep the dependency relationship between webwolf and commons-io:LATEST, which is a missing component. The bom looks as follows

Summarising the issues

We have three different scenarios here, however each has the same root cause. Maven is returning a dependency graph which includes marker nodes referencing the original artifact versions and not the versions resolved within the context of the build. These marker nodes have a different identity to the resolved dependencies and are, therefore, treated separately. As we would expect, identity does matter!

With the upstream codebase we see the resolved components being included in the bom, but with certain dependency relationships missing from the dependency tree.

With my pull request we see some missing components from the bom, but with all dependency relationships included in the dependency tree. The problem is that some of these relationships reference dependencies with their original version and not the version resolved by maven.

Note: The issues we are seeing do not happen with dependencies which have their version managed, if we look at the node for a managed dependency we can see the version of the marker has been updated

org.slf4j:slf4j-api:1.7.25:compile    (org.slf4j:slf4j-api:jar:1.7.25:compile - version managed from 1.6.6; omitted for duplicate)

In this case the version of the marker node has been updated from 1.6.6 to 1.7.25.

Unfortunately this additional information is not available to us other than through the toNodeString method on the VerboseDependencyNode class, that is unless we delve under the covers and work on the internal aether dependency tree which does contain a data map including this information.

Now for the solution

Now we have identified a root cause there is an obvious solution. We know maven is not updating the versions for some marker nodes, leaving them with their original version, so we need to handle this aspect. We need to track the versions of the resolved artifacts and, when creating the dependency graph, ensure all dependency versions reference the resolved version of the artifact. Thankfully this is a straight forward update to the codebase.

Now that we have a working solution how does this look for each component?

Recap and Solution for guava

From our earlier discussion we saw the upstream plugin had identified the correct guava version for the component, but had lost all dependency relationships, and my pull request had kept the dependency relationships but had lost the component as it was referring to the original version of the artifact. What do we see now in the bom file?

Fantastic, we now see a component with the version resolved by maven and all the dependency relationships we were expecting!

Recap and Solution for commons-lang3

From our earlier discussion we saw a similar issue with commons-lang3. The upstream plugin had identified the correct commons-lang3 version for the component, but had lost all dependency relationships, and my pull request had kept the dependency relationships but had lost the component as it was using the original version of the artifact. What do we see now in the bom file?

We are now two for two, we again see the component with the resolved version and also see all the dependency relationships!

Recap and Solution for jquery

In our earlier discussion we had identified a slightly different scenario with jquery, as the compile scoped artifacts included both the resolved version (3.2.1) and an older version (1.11.1). Both plugins had identified the component and included the dependency relationship between webwolf and jquery, however the upstream plugin had lost the dependency relationship between bootstrap and jquery whereas my pull request included the dependency but referenced the original version. What do we now see in the bom file?

We are on a roll, and are now three for three. We can see all the expected dependency relationships are present with all the relationships referencing the resolved version!

Recap and Solution for commons-io

Now we come to our final scenario and the use of metaversions, can we make it four for four?

In our earlier discussion we covered the use and meaning of metaversions within maven dependencies and saw the upstream plugin had correctly identified the resolved component, but had no dependency relationships, whereas my pull request identified the dependency relationships using the LATEST metaversion but did not identify the component. What do we now see in the bom file?

Brilliant, the component and all expected dependency relationships are present, with each referencing the resolved version and not the metaversion!

We have done it, we are now four for four!

Conclusions

With this latest issue now resolved I feel we have a much better solution for generating SBOMs for maven projects. We know these bom files will contain all dependency relationships returned via maven, and now this version mismatch issue has been addressed we can be confident we will only include entries for resolved artifacts.

My original pull request has been updated to include the fix for these issues, in addition to the issues covered in the previous post (An Adventure with the CycloneDX Maven Plugin), and has now been merged into the upstream codebase with help from Hervé. I'm looking forward to having this released in the next CycloneDX Maven Plugin release and being able to use this in earnest as part of our effort to secure our Software Supply Chain. With any luck this can also be of benefit to your efforts, at least I hope that proves to be the case.

The Update Framework (TUF)

2023-01-31T00:00:00.000Z

TUF seems to pop again and again when learning about Secure Supply-Chain Security (SSCS). The goal of this post is to get some hands-on experience with TUF, showing examples that will hopefully clarify TUF concepts, and the reason for using it in projects like Sigstore.

As the name "The Update Framework" implies this is a framework for update systems, and doing so in a secure way. What is getting updated could be anything, it could be software packages, source files, certificates, public keys, etc. And by following this "framework", updates can be performed in a secure way.

Producers want the things they produce to be available to consumers, and they want to make sure that consumers are getting updates for these things. I'm using "things" just to make it clear that this does not have to be software packages which might be what first comes to mind.

Lets take a look what this might look like without TUF:

  +-----------+     +---------------------+                      +----------+
  | Producer  |     | Distribution server |                      | Consumer |
  |-----------+     |---------------------+                      |----------|
  | thing_v1  | --> | thing_v1            | -------------------> | thing_v1 |
  +-----------+     +---------------------+                      +----------+

So we have a producer that has something that it makes available to consumer's via a distribution server. The consumer uses this thing by downloading it from the distribution server in some manner. If the distribution server just allows the consumer to poll and download the thing/artifact, then it will be up to the consumer code to decide when it should poll to check for updates and update if needed.

For example, lets say that a man in the middle (MITM) attack is put in place and the consumer is no longer talking to the distribution server but instead to server controlled by an attacker which provides the consumer with a malicious artifacts:

  +-----------+     +---------------------+     +----------+     +----------+
  | Producer  |     | Distribution server |     | MITM     |     | Consumer |
  |-----------+     |---------------------+     |          |     |----------|
  | thing_v1  | --> | thing_v1            |     | evil_v1  | --> | thing_v1 |
  +-----------+     +---------------------+     +----------+     +----------+

An attacker may also target the distribution server itself and modify the artifacts that the consumers download:

  +-----------+     +---------------------+                      +----------+
  | Producer  |     | Distribution server |                      | Consumer |
  |-----------+     |---------------------+                      |----------|
  | thing_v1  | --> | thing_v1 (evil_v1)  | ------------------>  | thing_v1 |
  +-----------+     +---------------------+                      +----------+

This type of attack is refered to as Arbitary software installation.

Another attack against the distribution server is where the attacker prevents the consumer from getting updates, and instead provides the consumer with an older version which might contain a known vulnerabilty.

This would be the current state where the correct/latest version is being used:

  +-----------+     +---------------------+                      +----------+
  | Producer  |     | Distribution server |                      | Consumer |
  |-----------+     |---------------------+                      |----------|
  | thing_v3  | --> | thing_v3            | ------------------>  | thing_v3 |
  +-----------+     +---------------------+                      +----------+

The attacker then changes the version on the distribution server to an older version, causing the consumer to downgrade, or rollback to that version:

  +-----------+     +---------------------+                      +----------+
  | Producer  |     | Distribution server |                      | Consumer |
  |-----------+     |---------------------+                      |----------|
  | thing_v3  | --> | thing_v2 (evil_v2)  | ------------------>  | thing_v2 |
  +-----------+     +---------------------+                      +----------+

This type of attack is refered to as Rollback attack.

There are other attacks but these I found helped me better understand the metadata that is provided by TUF.

A simplified overview of this can be seen below and I'm going into more details later in the document.

What I'd like to convey with this is that the producer will update the TUF repository by creating metadata about the artifact(s) that are going to be made available. This metadata is signed by one or more keys. The motivation for signing is that we want to prevent the situation above where an attacker is able to replace an artifact with an older version, or a modified version. Having the metadata signed for each version means that it would not be possible for an attacker to do this as the TUF client framework will verify signatures.

In TUF, the "distribution server" in the above scenarios will have a TUF repository integrated into it. This repository will be updated by the producer, and the consumer in the above scenarios will be replaced by a TUF client:

  +-----------+         +---------------------+               +------------------+
  | Producer  |         | TUF Repository      | <-----------  | TUF Client       |
  |-----------+ update  |---------------------+               |------------------|
  | thing_v1  | ------> | Metadata (signed)   | ------------> | Metadata (signed)|
  +-----------+         +---------------------+               +------------------+
                                                ------------> | thing_v1         |
                                                              +------------------+

Notice that in addition to the metadata that exists on the TUF repository there is also metadata on the TUF consumer/client side. This metadata is downloaded and frequently resigned, and it has an short expiration date. This is how the TUF framework enforces updates actually take place. Because the TUF client framework checks the expiration and the signature of the metadata file, it can detect if the expiration date has passed. If there has not been any updates and the expiration date has passed, perhaps a certain number of times, it can take action to notify the client side software about this situation. This is how TUF can enforce that updates actually get applied to the consumer.

This metadata is also signed as we don't want an attacker to be able to serve the client with a metadata file they crafted themselves, which might have enabled the attacker to trick the consumer into thinking that there are no updates and force the consumer to be stuck on an older version.

Hopefully this has provided an overview and some idea about the metadata and the signing in TUF. Later we will see a concrete example of the metadata files to get "feel" for what they look like.

So, we have mentioned metadata files and signing. The following is an attempt to visualize where the metadata files exist.

Initially, we would have the following metadata files:

  +-----------+         +---------------------+               +---------------+
  | Producer  |         | TUF Repository      |               | TUF Consumer  |
  |-----------+ update  |---------------------+               |---------------|
  | Keys      | ------> | Metadata            |               | Metadata      |
  +-----------+         | 1.root.json         |               | root.json     |
  | Metadata  |         | 1.targets.json      |               +---------------+
  | root.json |         | 1.snapshot.json     |
  +-----------+         | timestamp.json      |
  | thing_v1  |         +---------------------+
  +-----------+         | thing_v1            |
                        +---------------------+

Initially, before the client has interacted with the TUF repository, the client has a trusted root.json metadata file. This file is shipped with the client and it does not matter if it's expire date has passed, as it will get updated once the client interacts with the TUF reporitory which is part of the client workflow of TUF's specification.

The client starts by loading this trusted root file.

Next, client proceeds to the download .root.json files from the TUF repository until it has reached the latest:

  +-----------+         +---------------------+               +---------------+
  | Producer  |         | TUF Repository      | <-----------  | TUF Consumer  |
  |-----------+ update  |---------------------+               |---------------|
  | Keys      | ------> | Metadata            | ------------> | Metadata      |
  +-----------+         | 1.root.json         |               | root.json     |
  | Metadata  |         | 1.targets.json      |               +---------------+
  | root.json |         | 1.snapshot.json     |
  +-----------+         | timestamp.json      |
  | thing_v1  |         +---------------------+
  +-----------+         | thing_v1            |
                        +---------------------+

Notice that the root.json is written on the client side without the version prefix. This will be used to verify the files that are download later.

Next, the client will download the timestamp metadata file:

  +-----------+         +---------------------+               +---------------+
  | Producer  |         | TUF Repository      | <-----------  | TUF Consumer  |
  |-----------+ update  |---------------------+               |---------------|
  | Keys      | ------> | Metadata            | ------------> | Metadata      |
  +-----------+         | 1.root.json         |               | root.json     |
  | Metadata  |         | 1.targets.json      |               | timestamp.json|
  | root.json |         | 1.snapshot.json     |               +---------------+
  +-----------+         | timestamp.json      |
  | thing_v1  |         +---------------------+
  +-----------+         | thing_v1            |
                        +---------------------+

And there will number of verifications performed on timestamp.json.

Next, the client will download the snapshot metadata file:

  +-----------+         +---------------------+               +---------------+
  | Producer  |         | TUF Repository      | <-----------  | TUF Consumer  |
  |-----------+ update  |---------------------+               |---------------|
  | Keys      | ------> | Metadata            | ------------> | Metadata      |
  +-----------+         | 1.root.json         |               | root.json     |
  | Metadata  |         | 1.targets.json      |               | timestamp.json|
  | root.json |         | 1.snapshot.json     |               | snapshot.json |
  +-----------+         | timestamp.json      |               +---------------+
  | thing_v1  |         +---------------------+
  +-----------+         | thing_v1            |
                        +---------------------+

And there will number of verifications performed on snapshot.json.

Next, the client will download the targets.json metadata file:

  +-----------+         +---------------------+               +---------------+
  | Producer  |         | TUF Repository      | <-----------  | TUF Consumer  |
  |-----------+ update  |---------------------+               |---------------|
  | Keys      | ------> | Metadata            | ------------> | Metadata      |
  +-----------+         | 1.root.json         |               | root.json     |
  | Metadata  |         | 1.targets.json      |               | timestamp.json|
  | root.json |         | 1.snapshot.json     |               | snapshot.json |
  +-----------+         | timestamp.json      |               | targets.json  |
  | thing_v1  |         +---------------------+               +---------------+
  +-----------+         | thing_v1            |
                        +---------------------+

And there will number of verifications performed on targets.json.

Finally, the client will fetch the actual target files, these are the actual artifacts.

The names of the metadata files are named after the four top level roles in TUF:

Root Delegates trust to specific keys for all the other top level roles
Target Signs metadata for the target files
Snapshot Signs metadata about the latest version of targets metadata
Timestamp Signs metadata about the latest version of the snapshot metadata

The following sections will take a closer look at these metadata files.

Root Metadata

Instead of having a single root key, there will often be multiple root keys which are stored in different offline locations, meaning that they are not accessible remotely. These are often hardware keys, like Yubikeys.

Root keys are often used together to sign other keys. These non-root keys can then be re-signed/revoked/rotated if/when needed.

Each role has metadata associated with it, and the specification defines a canonical json format for them. So there would be a root.json, a targets.json, a, timestamps.json, and a snapshot.json.

So what do these file look like?

Lets try this out by using a tool called tuftool:

$ cargo install --force tuftool

Root metadata

Next we initiate a new root.json file using the following command:

$ tuftool root init root/root.json

This command will generate a file named root/root.json:

$ cat root/root.json
{
  "signed": {
    "_type": "root",
    "spec_version": "1.0.0",
    "consistent_snapshot": true,
    "version": 1,
    "expires": "2023-01-17T07:48:23Z",
    "keys": {},
    "roles": {
      "timestamp": {
        "keyids": [],
        "threshold": 1507
      },
      "root": {
        "keyids": [],
        "threshold": 1507
      },
      "snapshot": {
        "keyids": [],
        "threshold": 1507
      },
      "targets": {
        "keyids": [],
        "threshold": 1507
      }
    }
  },
  "signatures": []
}

These are just the default values, and we can see that there are no root keys, that field is just an empty object, and notice that the roles are mainly empty apart from the threshold values which is 1507. The threshold value specifies the minimum number of keys required to sign that roles metadata. 1507 is a large number of keys and we can change this to just requiring one key:

$ tuftool root set-threshold root/root.json snapshot 1
$ tuftool root set-threshold root/root.json root 1
$ tuftool root set-threshold root/root.json timestamp 1
$ tuftool root set-threshold root/root.json targets 1

And we can see that root/root.json has been updated:

$ cat root/root.json
{
  "signed": {
    "_type": "root",
    "spec_version": "1.0.0",
    "consistent_snapshot": true,
    "version": 1,
    "expires": "2023-02-27T14:05:04Z",
    "keys": {},
    "roles": {
      "root": {
        "keyids": [],
        "threshold": 1
      },
      "targets": {
        "keyids": [],
        "threshold": 1
      },
      "snapshot": {
        "keyids": [],
        "threshold": 1
      },
      "timestamp": {
        "keyids": [],
        "threshold": 1
      }
    }
  },
  "signatures": []
}

We can also set the expire time for the root using the following command:

$ tuftool root expire root/root.json 'in 6 weeks'

Now, to sign anything we will need a private key to create the signatures and a matching public key to be used to verify signatures.

We can generate a root key and one can be generated using tuftool root gen-rsa-key:

$ tuftool root gen-rsa-key root/root.json ./keys/root.pem --role root
6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f

This will generate keys/root.pem which is a private key in pkcs8 format. The hex value printed above is the key_id which will be used later to reference this key in metadata files.

Now, if we again inspect root.json we find that a key has been added:

$ cat root/root.json
{
  "signed": {
    "_type": "root",
    "spec_version": "1.0.0",
    "consistent_snapshot": true,
    "version": 1,
    "expires": "2023-02-28T08:30:48Z",
    "keys": {
      "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f": {
        "keytype": "rsa",
        "keyval": {
          "public": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5ZiWzak3CBJkRrCfw5GO\nSUtYjIK2jLozyaZ44FePW/KYEhM8LyHcNz9lwx45tZ8gId4AsxGBj9fhsOgjpN7l\nMPXpaKsV/5f37HzQLCrbldz3ei9LkMWG5La4Cwil0qPDpTxfzI7IWDKk6l4/epgi\nOrAJDaQ/mKhH5OZ485JYuDIE7a0jplU/GvsNeCdZVMEQ8dko/CA4Di8lPkDRRdSw\naC/8g3K6mF+87ADdGOmZ+LFodLEPvqIVljece2JlX2z44Io3N7Y5FH63Az4H3MFL\nDPZJH5lFs7Lb/fHx25rWSE2/GHcUUTs4oScPp2X0hAnblOsmCFSCjf8Kb0R7dLUb\nnQIDAQAB\n-----END PUBLIC KEY-----"
        },
        "scheme": "rsassa-pss-sha256"
      }
    },
    "roles": {
      "timestamp": {
        "keyids": [],
        "threshold": 1
      },
      "targets": {
        "keyids": [],
        "threshold": 1
      },
      "root": {
        "keyids": [
          "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f"
        ],
        "threshold": 1
      },
      "snapshot": {
        "keyids": [],
        "threshold": 1
      }
    }
  },
  "signatures": []
}

Notice that the keys object has a field which is named after the key_id and that the root role has this key_id in its keyids array. This key_id is created from the json value of the fields keytype, keyval, and scheme, which is then canonicalized before hashed using sha256. We can inspect/verify this using a tool named tuf-keyid, and passing in the above json field of the public key:

$ tuf-keyid --json='{
            "keytype": "rsa",
            "keyval": {
              "public": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5ZiWzak3CBJkRrCfw5GO\nSUtYjIK2jLozyaZ44FePW/KYEhM8LyHcNz9lwx45tZ8gId4AsxGBj9fhsOgjpN7l\nMPXpaKsV/5f37HzQLCrbldz3ei9LkMWG5La4Cwil0qPDpTxfzI7IWDKk6l4/epgi\nOrAJDaQ/mKhH5OZ485JYuDIE7a0jplU/GvsNeCdZVMEQ8dko/CA4Di8lPkDRRdSw\naC/8g3K6mF+87ADdGOmZ+LFodLEPvqIVljece2JlX2z44Io3N7Y5FH63Az4H3MFL\nDPZJH5lFs7Lb/fHx25rWSE2/GHcUUTs4oScPp2X0hAnblOsmCFSCjf8Kb0R7dLUb\nnQIDAQAB\n-----END PUBLIC KEY-----"
            },
            "scheme": "rsassa-pss-sha256"
    }'

key_id: SHA256:6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f

And we can see that the key_id's produced are the same. This may be obvious but just to be clear, keys only includes the public key.

Targets metadata

The Target role is a role that signs metadata files that describe the project artifacts, like software packages, source code, or whatever artifacts that are to be consumed by TUF clients/consumers.

So lets add a target key, and we will use the same private key as before:

$ tuftool root add-key root/root.json ./keys/root.pem --role targets
6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f

This will update the targets role in root.json:

$ jq '.signed.roles.targets' < root/root.json
{
  "keyids": [
    "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f"
  ],
  "threshold": 1
}

Snapshot metadata

The Snapshot roles signs a metadata file which contains information about the latest version of the targets metadata. This is used to identify which versions of a target are in a repository at a certain time. This is used to know if there is an update available (remember it's call The Update Framework).

So, lets add a key to the snapshot role:

$ tuftool root add-key root/root.json ./keys/root.pem --role snapshot

And we can see that following change to root.json:

$ jq '.signed.roles.snapshot' < root/root.json
{
  "keyids": [
    "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f"
  ],
  "threshold": 1
}

Timestamp metadata

Finally, we have the timestamp role which tells if there is an update.

$ tuftool root add-key root/root.json ./keys/root.pem --role timestamp

And we can see that following change to root.json:

$ jq '.signed.roles.timestamp' < root/root.json
{
  "keyids": [
    "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f"
  ],
  "threshold": 1
}

Signing root.json

So we have configured which keys to be used for each of the roles but we have not signed this metadata file. We need to sign it to prevent tampering of it as it will be sent to the TUF repository, usually on server but for this example everything will be on the local file system.

We can now sign root.json using the following command:

$ tuftool root sign ./root/root.json -k ./keys/root.pem

And we can check root.json that the signatures field has been updated with a keyid and a signature.

 jq '.signatures' < root/root.json
[
  {
    "keyid": "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f",
    "sig": "8e7c7ca88e242ff360af30ba83e0ccfd9de2a9dee774166abe508ad2757620d6439bc7a5163c55867e069812a21ba31b7097d9ded3590f03f8bdc7106755a9ae840efbfe9b6c7d69e047230c59f3bd682e83f0b5b9c271d6db60943f7fa57d565790de58687560b50951a363725471c3a8f64c3980385eb214876bb1fe87d4aefc5cdd557bd022ddd794a52368f8502c1944185c75827ca97bba8fd5cdd5bb41b7ad76f0105072fbee980d3dbbf9889ec223ea1399228560fd747bc03a378d3ba93990560b000d02a59aab04844ec70662f8baaee33f8591f5bbe3126fb057f9b3055d498005220d1715c92166506995e89f2e8e62d1032452d51ba6579eb0e2"
  }
]

Generate the TUF repository

With root.json and the private key we can generate a tuf repository using the following command:

$ tuftool create \
  --root root/root.json \
  --key keys/root.pem \
  --add-targets artifacts \
  --targets-expires 'in 3 weeks' \
  --targets-version 1 \
  --snapshot-expires 'in 3 weeks' \
  --snapshot-version 1 \
  --timestamp-expires 'in 1 week' \
  --timestamp-version 1 \
  --outdir repo

That command will create a directory named repo which contains two directories, metadata and targets.

Let start by looking at the targets directory:

$ ls -l repo/targets/01ab0faaf41a4543df1fa218b8e9f283d07536339cf11d2afae9d116a257700c.artifact_1.txt
lrwxrwxrwx. 1 danielbevenius danielbevenius 79 Jan 17 12:50 repo/targets/01ab0faaf41a4543df1fa218b8e9f283d07536339cf11d2afae9d116a257700c.artifact_1.txt -> artifacts/artifact_1.txt

Notice that the name of this link is the sha256sum of the contents of artifact_1.txt file:

$ sha256sum  artifacts/artifact_1.txt
01ab0faaf41a4543df1fa218b8e9f283d07536339cf11d2afae9d116a257700c  artifacts/artifact_1.txt

And we can check the size of this file using:

$ stat -c "%s" artifact_1.txt
24

The reason for showing this values is that they are referred to in the next section.

Now, lets take a look at the metadata directory.

$ ls repo/metadata/
1.root.json  1.snapshot.json  1.targets.json  timestamp.json

The number prefix is the version, to 1.targets.json is for version 1 for example.

Lets start by looking at targets.json:

{
  "signed": {
    "_type": "targets",
    "spec_version": "1.0.0",
    "version": 1,
    "expires": "2023-02-07T11:50:00.608598188Z",
    "targets": {
      "artifact_1.txt": {
        "length": 24,
        "hashes": {
          "sha256": "01ab0faaf41a4543df1fa218b8e9f283d07536339cf11d2afae9d116a257700c"
        }
      }
    },
    "delegations": {
      "keys": {},
      "roles": []
    }
  },
  "signatures": [
    {
      "keyid": "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f",
      "sig": "48b9810f275e16acb2d093c5487da4107f2312e0c9e084f6974aa836661a0e87d341be37fe84a4afd6ba82e8e54301e01a7431a0e69d3bef95ce3e34d90badff3c4a19ed7a6cea2a4ec69c6dc7392fde1f20b1246f3113ace85a223bfc54203a9254e82c8cd9686b8b973bfc41cdda657ff707a41c3db125b61dfc41c8937896f7fcc0ea17429a934b9c0fee912ca4df4a3b1dac6811968aa34bbf2d3327bbeab9cad1dadc1f8134c0add4267bf8ff285c066d24ea39b24d9bca197bf9762025133205612d41b167ee1232adf8c122320d77b70b936817ddf2cc93732228f772078b663f3fc896ec8873873414ba44fd3e28772589f69af06ee3e1297e0b2b37"
    }
  ]
}

Notice that the hashes object has a single field which is the sha256sum of the file artifacts_1.txt, and that length matches the size which we showed in the previous section.

We have information about the targets, in this case on a single file named artifact_1.txt, and this is the file that a client wants to consume. This metadata file is signed and the signature in the sig field of the signatures array.

Again, this needs to be signed to prevent an attacker from modifying the targets and modifying the length, and sha256 fields which would otherwise allow them to replace the target artifact with a potentially malicious version.

Next, lets take a look at the snapshots.json metadata file:

$ cat repo/metadata/1.snapshot.json
{
  "signed": {
    "_type": "snapshot",
    "spec_version": "1.0.0",
    "version": 1,
    "expires": "2023-02-07T11:50:00.608597347Z",
    "meta": {
      "targets.json": {
        "length": 1048,
        "hashes": {
          "sha256": "896781ff1260ed4ad5b05a004b034279219dc92b64068a2cc376604e8a6821c9"
        },
        "version": 1
      }
    }
  },
  "signatures": [
    {
      "keyid": "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f",
      "sig": "5a8d9597329183c52547591d1abc8e36c1535d81c0e51ed51d95d2ddf1ec2076f2412ba8e631f039c7bf9e5a14cdd44eb7a5c7dae5dcc84e6aa2ebd51049ee791cf3c3dc486af26731fc06ba39e449ef85b102247c4254cb48784e4a95b54943df9e668470a6def79c7c3d532a68e93d18f1d59f1636455dddec0b5960afeb5a9ac38c38c6891e6f819f22aed7996a7f9964d655d634a940e1234f2015caa8f4f710570443bc0bc3ec04117c3dc97c8d564f42489cc499593f6232b7f5062646644aecafaf50dc9a4005a000f6720b0b9c455e5b92d7a1bcfb96f14a6a9da162e9b091497b0eb24283a837ba1d15ff67f12d104b1c5e1d83c36ae49400bb326e"
    }
  ]
}

So looking at the above meta field, we can see that there is a targets.json "meta path". If we search for this file we won't be able to find it. The actual file is prefixed with the version from the version field. So the file in question is repo/metadata/1.targets.json, and we can check the size of this file using:

$ stat -c "%s" repo/metadata/1.targets.json
1048

And that matches the length field above.

And we also can check the hash using:

$ sha256sum repo/metadata/1.targets.json
896781ff1260ed4ad5b05a004b034279219dc92b64068a2cc376604e8a6821c9  repo/metadata/1.targets.json

The snapshot metadata file tells us which versions of metadata files existed for a specific version. Even though we only have one version currently in our example, a real world repositories would have multiple versions of metadata files. The purpose of the snapshot.json file is to prevent an attacker from including metadata files from another version in some version:

       TUF Repository              TUF Client
     +----------------+           +----------------+
     | timestamp.json | --------> | timestamp.json |
     | 1.targets.json | version 3 | - version 3    |
     | 2.targets.json | <-------  |                |
     | 3.targets.json | version 2 |                |
     |                | --------> |                |
     +----------------+           +----------------+kk

The above is trying to show that the client has received a timestamp.json, which we will discuss shortly, with a version number of 3. The client proceeds to retrieve this version update from the TUF server. Now if an attacker was able to include other metadata files, which are available in the TUF repository only they are not part of the request version, it would be possible for them those targets to be sent to the client.Having the snapshot.json prevents this as it specifies which metadata files are included in a specific version and no other additional metadata files that may exist in the TUF repository are included.

So that leaves us with timestamp.json. This is a file that is downloaded by the client and usually has a short expiration date. As mentioned before this is the part that allows the system to enforce that updates are actually reaching consumers, and if they are not they allow the consumer to take action.

The metadata looks like this:

$ cat repo/metadata/timestamp.json
{
  "signed": {
    "_type": "timestamp",
    "spec_version": "1.0.0",
    "version": 1,
    "expires": "2023-01-24T11:50:00.608598985Z",
    "meta": {
      "snapshot.json": {
        "length": 1004,
        "hashes": {
          "sha256": "b92c443c21b6bc15d4f3991491e8bcb201f66a26ab289fb8cc9af7f851530872"
        },
        "version": 1
      }
    }
  },
  "signatures": [
    {
      "keyid": "6e99ec437323f2c7334c8b16fd7a7a197829ba89ff50d07aa4b50fc9634dad9f",
      "sig": "3708f055fe58b2c70e92cbc46bd9cc0f3149900bf25b3e924ff666eb8b45187df8d1f064b249cd790c170b5e97b322866d298d527ff950d2fbcbf508097868afca34ebaa159890799155c6bb615bab9a8bcfc34a39574584716d9a89b531fce97d876884fad2db69dc8f3569870dee280e87c9d506b5b08698e7c23e7dbbf4a3209fbc91ec764b54bf87367145cbb7bc9d7edaf47f709355284315fac9167312833d990e9e064852bb4fa905ec4edb5fe051480e70d505694528c5e9b47fefc3b78f6e54623f93344511326bdeec392a5eac31e7299bf9f602036d9f9524810eb03c4720370250f3e9f503e8d5bee94a6e6539ca9f988a27272d47612fd03436"
    }
  ]
}

Notice that snapshot.json is refering to the file 1.timestamp.json in the TUF repository.

Finally, we have repo/metadata/1.root.json which is identical to root/root.json which we saw previously as this is the only version we have in our repository.

What we have been doing is setting up a repository which would be most often exist on on a server somewhere.

TUF client/consumer

A consumer of the artifact would use a TUF client library to download the artifacts, and would specify the metadata and targets to download.

To make this more concrete we have created a very basic example which is intended to show how one such client library, in this case tough, might be used. Please refer to the example's README.md for details.

TUF usage in Sigstore

Armed with the above knowledge, lets take a look at how Sigstore uses TUF.

The root-signing repository has a directory which contains the TUF repository metadata.

Sigstore uses TUF to protect their public keys and certificates, which was one reason for trying to say "things" instead of software updates in the text above. So the artifacts that are updated are public keys and certificates. As of this writing these are the current targets:

fulcio.crt.pem  Fulico (CA) certificate.
rekor.pub       Rekor public key.
ctfe.pub        Certificate Transparency log public key used to verify
                signed certificate timestamps.
artifact.pub    Public key which is used to verify Sigstore releases, like
                Cosign, Rekor, and Fulcio releases.

There are more than four in the actual file but they are different versions. The four listed here just explain the usage of these keys. In the case of sigstore-rs only the Fulio certificate, and Rekor's public key are used. We will focus on these in this post.

The root.json can also be found in the same directory and hopefully this should look familar after seeing the root.json earlier.

We also learned earlier that the initial trusted root.json is shipped with the software in some manner. In sigstore-rs, root.json is a constant named SIGSTORE_ROOT in the crate itself.

sigstore-rs uses the tough crate just like the example we saw earlier, and similar to the example, creates a tough RepositoryLoader in a RepositoryHelper struct. A RepositoryHelper is created in SigstoreRepository's fetch method, and the Fulcio certificate, and Rekor's public key are read from the repository, similar to how artifact.txt was read in the example:

    let repository_helper = RepositoryHelper::new(
        SIGSTORE_ROOT.as_bytes(),
        metadata_base,
        target_base,
        checkout_dir,
    )?;

    let fulcio_certs = repository_helper.fulcio_certs()?;

    let rekor_pub_key = repository_helper.rekor_pub_key().map(|data| {
        String::from_utf8(data).map_err(|e| {
            SigstoreError::UnexpectedError(format!(
                "Cannot parse Rekor's public key obtained from TUF repository: {}",
                e
            ))
        })
    })??;

There is a caching layer in-between the call to fulcio_certs but after that, and if there is a cache miss, the actual call the TUF repository can be found in fetch_target:

/// Download a file from a TUF repository
fn fetch_target(repository: &tough::Repository, target_name: &TargetName) -> Result<Vec<u8>> {
    let data: Vec<u8>;
    match repository.read_target(target_name)? {
        None => Err(SigstoreError::TufTargetNotFoundError(
            target_name.raw().to_string(),
        )),
        Some(reader) => {
            data = read_to_end(reader)?;
            Ok(data)
        }
    }
}

And this is simliar to how in the example above we downloaded artifact.txt like this:

    let artifact = repository
        .read_target(&TargetName::from_str("artifact.txt").unwrap())
        .unwrap();

By using the TUF framework for Fulcio's certificate, and Rekor's public keys these can be updated in a secure manner like described previously in this post.

Is this a cryptographic key which I see before me?

2023-01-25T00:00:00.000Z

Yes, it is. Really? Then what format is it in and how can I tell?

I've found myself in this situation a number of times and this post tries to provide some guidelines for figuring out the type and format of keys without having to go off and read some project's documentation.

To start off we can try to determine if the key is in a PEM format, or in DER format.

Keys in PEM format are in ascii and can be inspected from the command line using cat, or opened in any text editor. For example:

$ cat pubkey.pem
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEDTvL0PRsxoxMXfSaXu+7w0ovVNzZ
k/BAIoz2GL2cPY3qZENU/+YrR92AuZFXn0jSmmvOktpAzGhnDhtidonkyA==
-----END PUBLIC KEY-----

If we try the same with DER format then we will get a bunch of strange characters printed. For example:

$ cat pubkey.der
;���lƌL]��^��J/T�ٓ�@"����=��dCT��+G݀��W�HҚkΒ�@�hgv���$

PEM formatted keys

So we have determined that the key we have in front of us is in PEM format. Now, if we take a look at the PEM output above again:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEDTvL0PRsxoxMXfSaXu+7w0ovVNzZ
k/BAIoz2GL2cPY3qZENU/+YrR92AuZFXn0jSmmvOktpAzGhnDhtidonkyA==
-----END PUBLIC KEY-----

We can see that it has a header and the footer. Notice that there is no information about the type of public key that this file contains. This means that the information about the type of key in baked in there somewhere. So how can we find out what the type of the key?
One option is to use the openssl asn1parse command:

$ openssl asn1parse -i  -in pubkey.pem
d=0  hl=2 l=  89 cons: SEQUENCE
d=1  hl=2 l=  19 cons:  SEQUENCE
d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
d=1  hl=2 l=  66 prim:  BIT STRING

And we can see, that there is an id here which is ecPublicKey.

As a rule of thumb, if there is no key type in the PEM header, then the format of the key is most probably in Subject Public Key Info (SPKI) if it is a public key, and in Public-Key Cryptography Standard 8 (pkcs8) format if it is a private key.

With the knowledge that the key is an Elliptic Curve (EC) public key we can use the following openssl command to inspect it:

$ openssl ec -pubin -in pubkey.pem --text --noout
read EC key
Public-Key: (256 bit)
pub:
    04:0d:3b:cb:d0:f4:6c:c6:8c:4c:5d:f4:9a:5e:ef:
    bb:c3:4a:2f:54:dc:d9:93:f0:40:22:8c:f6:18:bd:
    9c:3d:8d:ea:64:43:54:ff:e6:2b:47:dd:80:b9:91:
    57:9f:48:d2:9a:6b:ce:92:da:40:cc:68:67:0e:1b:
    62:76:89:e4:c8
ASN1 OID: prime256v1
NIST CURVE: P-256

Some PEM keys can also be in a specific key format, in which case the type is in the header of the pem, for example:

-----BEGIN RSA PUBLIC KEY-----
...
-----END RSA PUBLIC KEY-----

And if needed we can use the openssl rsa command to inspect them further.

The same reasoning can be applied to private keys as well with regards to the PEM header/footer information, and in the case of private keys the -pubin argument to the openssl commands should left out.

DER formatted keys

As mentioned before we can't just print DER files as they are in binary format, but we can still use openssl asn1parse:

$ openssl asn1parse -i -inform der  -in pubkey.der
d=0  hl=2 l=  89 cons: SEQUENCE
d=1  hl=2 l=  19 cons:  SEQUENCE
d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
d=1  hl=2 l=  66 prim:  BIT STRING

And just like with the PEM example we can use other openssl tools to inspect the key.

When the guidelines fail

The above seems to work for most situations, but it can fail.

One example of this is when openssl cannot parse the key at all. I ran into this recently with in-toto-rs, which uses the Rust ring crate to handle Ed25519 keys.

The issue here is that ring supports pkcs8 version 2 (RFC-5958), and OpenSSL currently only supports pkcs8 version 1 (RFC-5208), so the openssl tools will not be able to parse keys in the version 2 format.

Below is an example of trying to use a version 2 formatted Ed25519 key with openssl:

$ openssl pkey -inform der -in ed25519-1 -pubout
Could not read key from ed25519-1

There is an open openssl issue for this.

Hopefully there will not be many cases like this, and we hope that the guidelines provided in this post are helpful.

Sigstore bundle format

2023-01-13T00:00:00.000Z

This post takes a look at Sigstore's bundle format which is the format of Sigstore's offline verification data.

Offline verification is described like this in busting-5-sigstore-myths:

Another common use case is that organizations need to run systems in air-gapped
environments with no outside network access. That means it’s not possible to
look up a signature in the transparency log, Rekor, right? Wrong! We use what’s
called "stapled inclusion proofs" by default, meaning you can verify an object
is present in the transparency log without needing to contact the transparency
log! The signer is responsible for gathering this evidence from the log and
presenting it alongside the artifact and signature. We store this in an OCI
image automatically, but you can treat it like a normal file and copy it around
for verification as well.

So, lets create a bundle and inspect the contents. First, we need to sign an artifact and in this case we are going to use a simple text file:

$ echo "some data" > artifact.txt

As mentioned, Sigstore can create a bundle, which contains all the information required for "stapled inclusion proofs". A bundle can be generated using the following command:

$ COSIGN_EXPERIMENTAL=1 cosign sign-blob --bundle=artifact.bundle artifact.txt
Using payload from: artifact.txt
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
        By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.

Are you sure you want to continue? (y/[N]): y
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=gGdRPWHb4ZNnBjRIEs9wbBhI3bqVriOCyq2W98YuqQ0&code_challenge_method=S256&nonce=2KGHDNf4CZ4gXINF9A12quVVxHl&redirect_uri=http%3A%2F%2Flocalhost%3A41711%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2KGHDOhtlyDhCegsNy1qPuKAWbd
Successfully verified SCT...
using ephemeral certificate:
-----BEGIN CERTIFICATE-----
MIICpzCCAi6gAwIBAgIUb6LDCNlvHnUGD55dbYuRq9BEB7gwCgYIKoZIzj0EAwMw
NzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl
cm1lZGlhdGUwHhcNMjMwMTEzMDcxMTIyWhcNMjMwMTEzMDcyMTIyWjAAMFkwEwYH
KoZIzj0CAQYIKoZIzj0DAQcDQgAEDTvL0PRsxoxMXfSaXu+7w0ovVNzZk/BAIoz2
GL2cPY3qZENU/+YrR92AuZFXn0jSmmvOktpAzGhnDhtidonkyKOCAU0wggFJMA4G
A1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUdZPv
Pd5abMkW8mcBgb3umAmHTcUwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4Y
ZD8wJwYDVR0RAQH/BB0wG4EZZGFuaWVsLmJldmVuaXVzQGdtYWlsLmNvbTAsBgor
BgEEAYO/MAEBBB5odHRwczovL2dpdGh1Yi5jb20vbG9naW4vb2F1dGgwgYoGCisG
AQQB1nkCBAIEfAR6AHgAdgDdPTBqxscRMmMZHhyZZzcCokpeuN48rf+HinKALynu
jgAAAYWp+AiYAAAEAwBHMEUCIAlfL870WJta7pD97Yiw0JbvY7YGg604cGxXEXtQ
tzoaAiEA+VWQiz+JPEsLBLbtclfhXFhn/C4kTyaS2Fj12+voTt4wCgYIKoZIzj0E
AwMDZwAwZAIwUtBB+1H6177KW3nfTpK9unSGgwIPEuNqQviJyeZRjkK85pnfk0p5
lwQVbfekXYq+AjBgJA/xjX5+UqRh+O1LqxBIun1gYhIwK+UUZq49SH0uP2sQL5un
ILHOPrBw0f00Q68=
-----END CERTIFICATE-----

tlog entry created with index: 11074687
Bundle wrote in the file artifact.bundle
MEUCIBbfVr0rREgk2yXfENMzTduXnSRc2GkJEUOb5tBncFgSAiEAtC4f1CA4Yio9N3wjdMAbY6hCerCKwyM+hn8L1kn33GE=

After this there will be an file named artifact.bundle in the directory where the above command was executed.

So lets take a look at the bundle:

$ cat artifact.bundle | jq
{
  "base64Signature": "MEUCIBbfVr0rREgk2yXfENMzTduXnSRc2GkJEUOb5tBncFgSAiEAtC4f1CA4Yio9N3wjdMAbY6hCerCKwyM+hn8L1kn33GE=",
  "cert": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNwekNDQWk2Z0F3SUJBZ0lVYjZMRENObHZIblVHRDU1ZGJZdVJxOUJFQjdnd0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpNd01URXpNRGN4TVRJeVdoY05Nak13TVRFek1EY3lNVEl5V2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVEVHZMMFBSc3hveE1YZlNhWHUrN3cwb3ZWTnpaay9CQUlvejIKR0wyY1BZM3FaRU5VLytZclI5MkF1WkZYbjBqU21tdk9rdHBBekdobkRodGlkb25reUtPQ0FVMHdnZ0ZKTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVVkWlB2ClBkNWFiTWtXOG1jQmdiM3VtQW1IVGNVd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d0p3WURWUjBSQVFIL0JCMHdHNEVaWkdGdWFXVnNMbUpsZG1WdWFYVnpRR2R0WVdsc0xtTnZiVEFzQmdvcgpCZ0VFQVlPL01BRUJCQjVvZEhSd2N6b3ZMMmRwZEdoMVlpNWpiMjB2Ykc5bmFXNHZiMkYxZEdnd2dZb0dDaXNHCkFRUUIxbmtDQkFJRWZBUjZBSGdBZGdEZFBUQnF4c2NSTW1NWkhoeVpaemNDb2twZXVONDhyZitIaW5LQUx5bnUKamdBQUFZV3ArQWlZQUFBRUF3QkhNRVVDSUFsZkw4NzBXSnRhN3BEOTdZaXcwSmJ2WTdZR2c2MDRjR3hYRVh0UQp0em9hQWlFQStWV1FpeitKUEVzTEJMYnRjbGZoWEZobi9DNGtUeWFTMkZqMTIrdm9UdDR3Q2dZSUtvWkl6ajBFCkF3TURad0F3WkFJd1V0QkIrMUg2MTc3S1czbmZUcEs5dW5TR2d3SVBFdU5xUXZpSnllWlJqa0s4NXBuZmswcDUKbHdRVmJmZWtYWXErQWpCZ0pBL3hqWDUrVXFSaCtPMUxxeEJJdW4xZ1loSXdLK1VVWnE0OVNIMHVQMnNRTDV1bgpJTEhPUHJCdzBmMDBRNjg9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K",
  "rekorBundle": {
    "SignedEntryTimestamp": "MEUCIQDYiu9WHR4eCJ2JGPCfwWYg/lILIM+9IvDEb3Nq2MYIUAIgK2tRLSYDLuU0uaywKy8C+3ETUBKfw1lds4Q4Bw4l8jQ=",
    "Payload": {
      "body": "eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI1YWEwM2Y5NmM3NzUzNjU3OTE2NmZiYTE0NzkyOTYyNmNjM2E5Nzk2MGU5OTQwNTdhOWQ4MDI3MWE3MzZkMTBmIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJQmJmVnIwclJFZ2syeVhmRU5NelRkdVhuU1JjMkdrSkVVT2I1dEJuY0ZnU0FpRUF0QzRmMUNBNFlpbzlOM3dqZE1BYlk2aENlckNLd3lNK2huOEwxa24zM0dFPSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2sxSlNVTndla05EUVdrMlowRjNTVUpCWjBsVllqWk1SRU5PYkhaSWJsVkhSRFUxWkdKWmRWSnhPVUpGUWpkbmQwTm5XVWxMYjFwSmVtb3dSVUYzVFhjS1RucEZWazFDVFVkQk1WVkZRMmhOVFdNeWJHNWpNMUoyWTIxVmRWcEhWakpOVWpSM1NFRlpSRlpSVVVSRmVGWjZZVmRrZW1SSE9YbGFVekZ3WW01U2JBcGpiVEZzV2tkc2FHUkhWWGRJYUdOT1RXcE5kMDFVUlhwTlJHTjRUVlJKZVZkb1kwNU5hazEzVFZSRmVrMUVZM2xOVkVsNVYycEJRVTFHYTNkRmQxbElDa3R2V2tsNmFqQkRRVkZaU1V0dldrbDZhakJFUVZGalJGRm5RVVZFVkhaTU1GQlNjM2h2ZUUxWVpsTmhXSFVyTjNjd2IzWldUbnBhYXk5Q1FVbHZlaklLUjB3eVkxQlpNM0ZhUlU1Vkx5dFpjbEk1TWtGMVdrWlliakJxVTIxdGRrOXJkSEJCZWtkb2JrUm9kR2xrYjI1cmVVdFBRMEZWTUhkblowWktUVUUwUndwQk1WVmtSSGRGUWk5M1VVVkJkMGxJWjBSQlZFSm5UbFpJVTFWRlJFUkJTMEpuWjNKQ1owVkdRbEZqUkVGNlFXUkNaMDVXU0ZFMFJVWm5VVlZrV2xCMkNsQmtOV0ZpVFd0WE9HMWpRbWRpTTNWdFFXMUlWR05WZDBoM1dVUldVakJxUWtKbmQwWnZRVlV6T1ZCd2VqRlphMFZhWWpWeFRtcHdTMFpYYVhocE5Ga0tXa1E0ZDBwM1dVUldVakJTUVZGSUwwSkNNSGRITkVWYVdrZEdkV0ZYVm5OTWJVcHNaRzFXZFdGWVZucFJSMlIwV1Zkc2MweHRUblppVkVGelFtZHZjZ3BDWjBWRlFWbFBMMDFCUlVKQ1FqVnZaRWhTZDJONmIzWk1NbVJ3WkVkb01WbHBOV3BpTWpCMllrYzVibUZYTkhaaU1rWXhaRWRuZDJkWmIwZERhWE5IQ2tGUlVVSXhibXREUWtGSlJXWkJValpCU0dkQlpHZEVaRkJVUW5GNGMyTlNUVzFOV2tob2VWcGFlbU5EYjJ0d1pYVk9ORGh5Wml0SWFXNUxRVXg1Ym5VS2FtZEJRVUZaVjNBclFXbFpRVUZCUlVGM1FraE5SVlZEU1VGc1prdzROekJYU25SaE4zQkVPVGRaYVhjd1NtSjJXVGRaUjJjMk1EUmpSM2hZUlZoMFVRcDBlbTloUVdsRlFTdFdWMUZwZWl0S1VFVnpURUpNWW5SamJHWm9XRVpvYmk5RE5HdFVlV0ZUTWtacU1USXJkbTlVZERSM1EyZFpTVXR2V2tsNmFqQkZDa0YzVFVSYWQwRjNXa0ZKZDFWMFFrSXJNVWcyTVRjM1MxY3pibVpVY0VzNWRXNVRSMmQzU1ZCRmRVNXhVWFpwU25sbFdsSnFhMHM0TlhCdVptc3djRFVLYkhkUlZtSm1aV3RZV1hFclFXcENaMHBCTDNocVdEVXJWWEZTYUN0UE1VeHhlRUpKZFc0eFoxbG9TWGRMSzFWVlduRTBPVk5JTUhWUU1uTlJURFYxYmdwSlRFaFBVSEpDZHpCbU1EQlJOamc5Q2kwdExTMHRSVTVFSUVORlVsUkpSa2xEUVZSRkxTMHRMUzBLIn19fX0=",
      "integratedTime": 1673593883,
      "logIndex": 11074687,
      "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"
    }
  }
}

So we have a json object with three fields, a base64Signature, a cert, and a rekorBundle field.

Lets start with base64Signature field:

$ cat artifact.bundle | jq '.base64Signature'
"MEUCIBbfVr0rREgk2yXfENMzTduXnSRc2GkJEUOb5tBncFgSAiEAtC4f1CA4Yio9N3wjdMAbY6hCerCKwyM+hn8L1kn33GE="

As the name of this field implies it contains a base64 encoded signature.

Lets be decode the signature and store it in a file:

$ cat artifact.bundle | jq -r '.base64Signature' | base64 -d - > signature

We will use this file shortly.

The cert field contains a base64 encoded certificate in pem format:

$ cat artifact.bundle | jq -r '.rekorBundle.Payload.body' | base64 -d - | jq -r '.spec.signature.publicKey.content' | base64 -d -
-----BEGIN CERTIFICATE-----
MIICpzCCAi6gAwIBAgIUb6LDCNlvHnUGD55dbYuRq9BEB7gwCgYIKoZIzj0EAwMw
NzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl
cm1lZGlhdGUwHhcNMjMwMTEzMDcxMTIyWhcNMjMwMTEzMDcyMTIyWjAAMFkwEwYH
KoZIzj0CAQYIKoZIzj0DAQcDQgAEDTvL0PRsxoxMXfSaXu+7w0ovVNzZk/BAIoz2
GL2cPY3qZENU/+YrR92AuZFXn0jSmmvOktpAzGhnDhtidonkyKOCAU0wggFJMA4G
A1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUdZPv
Pd5abMkW8mcBgb3umAmHTcUwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4Y
ZD8wJwYDVR0RAQH/BB0wG4EZZGFuaWVsLmJldmVuaXVzQGdtYWlsLmNvbTAsBgor
BgEEAYO/MAEBBB5odHRwczovL2dpdGh1Yi5jb20vbG9naW4vb2F1dGgwgYoGCisG
AQQB1nkCBAIEfAR6AHgAdgDdPTBqxscRMmMZHhyZZzcCokpeuN48rf+HinKALynu
jgAAAYWp+AiYAAAEAwBHMEUCIAlfL870WJta7pD97Yiw0JbvY7YGg604cGxXEXtQ
tzoaAiEA+VWQiz+JPEsLBLbtclfhXFhn/C4kTyaS2Fj12+voTt4wCgYIKoZIzj0E
AwMDZwAwZAIwUtBB+1H6177KW3nfTpK9unSGgwIPEuNqQviJyeZRjkK85pnfk0p5
lwQVbfekXYq+AjBgJA/xjX5+UqRh+O1LqxBIun1gYhIwK+UUZq49SH0uP2sQL5un
ILHOPrBw0f00Q68=
-----END CERTIFICATE-----

We can inspect this certificate using openssl:

$ cat artifact.bundle | jq -r '.rekorBundle.Payload.body' | base64 -d - | jq -r '.spec.signature.publicKey.content' | base64 -d - | openssl x509 -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6f:a2:c3:08:d9:6f:1e:75:06:0f:9e:5d:6d:8b:91:ab:d0:44:07:b8
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: O = sigstore.dev, CN = sigstore-intermediate
        Validity
            Not Before: Jan 13 07:11:22 2023 GMT
            Not After : Jan 13 07:21:22 2023 GMT
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:0d:3b:cb:d0:f4:6c:c6:8c:4c:5d:f4:9a:5e:ef:
                    bb:c3:4a:2f:54:dc:d9:93:f0:40:22:8c:f6:18:bd:
                    9c:3d:8d:ea:64:43:54:ff:e6:2b:47:dd:80:b9:91:
                    57:9f:48:d2:9a:6b:ce:92:da:40:cc:68:67:0e:1b:
                    62:76:89:e4:c8
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                Code Signing
            X509v3 Subject Key Identifier:
                75:93:EF:3D:DE:5A:6C:C9:16:F2:67:01:81:BD:EE:98:09:87:4D:C5
            X509v3 Authority Key Identifier:
                keyid:DF:D3:E9:CF:56:24:11:96:F9:A8:D8:E9:28:55:A2:C6:2E:18:64:3F

            X509v3 Subject Alternative Name: critical
                email:daniel.bevenius@gmail.com
            1.3.6.1.4.1.57264.1.1:
                https://github.com/login/oauth
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : DD:3D:30:6A:C6:C7:11:32:63:19:1E:1C:99:67:37:02:
                                A2:4A:5E:B8:DE:3C:AD:FF:87:8A:72:80:2F:29:EE:8E
                    Timestamp : Jan 13 07:11:22.776 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:09:5F:2F:CE:F4:58:9B:5A:EE:90:FD:ED:
                                88:B0:D0:96:EF:63:B6:06:83:AD:38:70:6C:57:11:7B:
                                50:B7:3A:1A:02:21:00:F9:55:90:8B:3F:89:3C:4B:0B:
                                04:B6:ED:72:57:E1:5C:58:67:FC:2E:24:4F:26:92:D8:
                                58:F5:DB:EB:E8:4E:DE
    Signature Algorithm: ecdsa-with-SHA384
         30:64:02:30:52:d0:41:fb:51:fa:d7:be:ca:5b:79:df:4e:92:
         bd:ba:74:86:83:02:0f:12:e3:6a:42:f8:89:c9:e6:51:8e:42:
         bc:e6:99:df:93:4a:79:97:04:15:6d:f7:a4:5d:8a:be:02:30:
         60:24:0f:f1:8d:7e:7e:52:a4:61:f8:ed:4b:ab:10:48:ba:7d:
         60:62:12:30:2b:e5:14:66:ae:3d:48:7d:2e:3f:6b:10:2f:9b:
         a7:20:b1:ce:3e:b0:70:d1:fd:34:43:af
-----BEGIN CERTIFICATE-----
MIICpzCCAi6gAwIBAgIUb6LDCNlvHnUGD55dbYuRq9BEB7gwCgYIKoZIzj0EAwMw
NzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl
cm1lZGlhdGUwHhcNMjMwMTEzMDcxMTIyWhcNMjMwMTEzMDcyMTIyWjAAMFkwEwYH
KoZIzj0CAQYIKoZIzj0DAQcDQgAEDTvL0PRsxoxMXfSaXu+7w0ovVNzZk/BAIoz2
GL2cPY3qZENU/+YrR92AuZFXn0jSmmvOktpAzGhnDhtidonkyKOCAU0wggFJMA4G
A1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUdZPv
Pd5abMkW8mcBgb3umAmHTcUwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4Y
ZD8wJwYDVR0RAQH/BB0wG4EZZGFuaWVsLmJldmVuaXVzQGdtYWlsLmNvbTAsBgor
BgEEAYO/MAEBBB5odHRwczovL2dpdGh1Yi5jb20vbG9naW4vb2F1dGgwgYoGCisG
AQQB1nkCBAIEfAR6AHgAdgDdPTBqxscRMmMZHhyZZzcCokpeuN48rf+HinKALynu
jgAAAYWp+AiYAAAEAwBHMEUCIAlfL870WJta7pD97Yiw0JbvY7YGg604cGxXEXtQ
tzoaAiEA+VWQiz+JPEsLBLbtclfhXFhn/C4kTyaS2Fj12+voTt4wCgYIKoZIzj0E
AwMDZwAwZAIwUtBB+1H6177KW3nfTpK9unSGgwIPEuNqQviJyeZRjkK85pnfk0p5
lwQVbfekXYq+AjBgJA/xjX5+UqRh+O1LqxBIun1gYhIwK+UUZq49SH0uP2sQL5un
ILHOPrBw0f00Q68=
-----END CERTIFICATE-----

Lets store the certificate in a file, and extract the public key:

$ cat artifact.bundle | jq -r '.rekorBundle.Payload.body' | base64 -d - | jq -r '.spec.signature.publicKey.content' | base64 -d -  > cert.pem
$ openssl x509 -pubkey -noout -in cert.pem  > pub.pem

With those files, the signature, the public key, and the blob we should be able to verify the signature from the base64Signature field using the following command:

$ openssl dgst -verify pub.pem -keyform PEM -sha256 -signature signature -binary artifact.txt
Verified OK

The motivation of doing that was to show that the base64Signature is just the signature of the blob.

Next, lets take a look at the rekorBundle field:

$ cat artifact.bundle | jq -r '.rekorBundle' |  jq '.'
{
  "SignedEntryTimestamp": "MEUCIQDYiu9WHR4eCJ2JGPCfwWYg/lILIM+9IvDEb3Nq2MYIUAIgK2tRLSYDLuU0uaywKy8C+3ETUBKfw1lds4Q4Bw4l8jQ=",
  "Payload": {
    "body": "eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI1YWEwM2Y5NmM3NzUzNjU3OTE2NmZiYTE0NzkyOTYyNmNjM2E5Nzk2MGU5OTQwNTdhOWQ4MDI3MWE3MzZkMTBmIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJQmJmVnIwclJFZ2syeVhmRU5NelRkdVhuU1JjMkdrSkVVT2I1dEJuY0ZnU0FpRUF0QzRmMUNBNFlpbzlOM3dqZE1BYlk2aENlckNLd3lNK2huOEwxa24zM0dFPSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2sxSlNVTndla05EUVdrMlowRjNTVUpCWjBsVllqWk1SRU5PYkhaSWJsVkhSRFUxWkdKWmRWSnhPVUpGUWpkbmQwTm5XVWxMYjFwSmVtb3dSVUYzVFhjS1RucEZWazFDVFVkQk1WVkZRMmhOVFdNeWJHNWpNMUoyWTIxVmRWcEhWakpOVWpSM1NFRlpSRlpSVVVSRmVGWjZZVmRrZW1SSE9YbGFVekZ3WW01U2JBcGpiVEZzV2tkc2FHUkhWWGRJYUdOT1RXcE5kMDFVUlhwTlJHTjRUVlJKZVZkb1kwNU5hazEzVFZSRmVrMUVZM2xOVkVsNVYycEJRVTFHYTNkRmQxbElDa3R2V2tsNmFqQkRRVkZaU1V0dldrbDZhakJFUVZGalJGRm5RVVZFVkhaTU1GQlNjM2h2ZUUxWVpsTmhXSFVyTjNjd2IzWldUbnBhYXk5Q1FVbHZlaklLUjB3eVkxQlpNM0ZhUlU1Vkx5dFpjbEk1TWtGMVdrWlliakJxVTIxdGRrOXJkSEJCZWtkb2JrUm9kR2xrYjI1cmVVdFBRMEZWTUhkblowWktUVUUwUndwQk1WVmtSSGRGUWk5M1VVVkJkMGxJWjBSQlZFSm5UbFpJVTFWRlJFUkJTMEpuWjNKQ1owVkdRbEZqUkVGNlFXUkNaMDVXU0ZFMFJVWm5VVlZrV2xCMkNsQmtOV0ZpVFd0WE9HMWpRbWRpTTNWdFFXMUlWR05WZDBoM1dVUldVakJxUWtKbmQwWnZRVlV6T1ZCd2VqRlphMFZhWWpWeFRtcHdTMFpYYVhocE5Ga0tXa1E0ZDBwM1dVUldVakJTUVZGSUwwSkNNSGRITkVWYVdrZEdkV0ZYVm5OTWJVcHNaRzFXZFdGWVZucFJSMlIwV1Zkc2MweHRUblppVkVGelFtZHZjZ3BDWjBWRlFWbFBMMDFCUlVKQ1FqVnZaRWhTZDJONmIzWk1NbVJ3WkVkb01WbHBOV3BpTWpCMllrYzVibUZYTkhaaU1rWXhaRWRuZDJkWmIwZERhWE5IQ2tGUlVVSXhibXREUWtGSlJXWkJValpCU0dkQlpHZEVaRkJVUW5GNGMyTlNUVzFOV2tob2VWcGFlbU5EYjJ0d1pYVk9ORGh5Wml0SWFXNUxRVXg1Ym5VS2FtZEJRVUZaVjNBclFXbFpRVUZCUlVGM1FraE5SVlZEU1VGc1prdzROekJYU25SaE4zQkVPVGRaYVhjd1NtSjJXVGRaUjJjMk1EUmpSM2hZUlZoMFVRcDBlbTloUVdsRlFTdFdWMUZwZWl0S1VFVnpURUpNWW5SamJHWm9XRVpvYmk5RE5HdFVlV0ZUTWtacU1USXJkbTlVZERSM1EyZFpTVXR2V2tsNmFqQkZDa0YzVFVSYWQwRjNXa0ZKZDFWMFFrSXJNVWcyTVRjM1MxY3pibVpVY0VzNWRXNVRSMmQzU1ZCRmRVNXhVWFpwU25sbFdsSnFhMHM0TlhCdVptc3djRFVLYkhkUlZtSm1aV3RZV1hFclFXcENaMHBCTDNocVdEVXJWWEZTYUN0UE1VeHhlRUpKZFc0eFoxbG9TWGRMSzFWVlduRTBPVk5JTUhWUU1uTlJURFYxYmdwSlRFaFBVSEpDZHpCbU1EQlJOamc5Q2kwdExTMHRSVTVFSUVORlVsUkpSa2xEUVZSRkxTMHRMUzBLIn19fX0=",
    "integratedTime": 1673593883,
    "logIndex": 11074687,
    "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"
  }
}

SignedEntryTimestamp is a signature of the logIndex, the body, and the integratedTime time fields created by Rekor. We can inspect the Rekor log entry to verify:

$ curl --silent https://rekor.sigstore.dev/api/v1/log/entries?logIndex=11074687 | jq -r '.[]'
{
  "body": "eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI1YWEwM2Y5NmM3NzUzNjU3OTE2NmZiYTE0NzkyOTYyNmNjM2E5Nzk2MGU5OTQwNTdhOWQ4MDI3MWE3MzZkMTBmIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJQmJmVnIwclJFZ2syeVhmRU5NelRkdVhuU1JjMkdrSkVVT2I1dEJuY0ZnU0FpRUF0QzRmMUNBNFlpbzlOM3dqZE1BYlk2aENlckNLd3lNK2huOEwxa24zM0dFPSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2sxSlNVTndla05EUVdrMlowRjNTVUpCWjBsVllqWk1SRU5PYkhaSWJsVkhSRFUxWkdKWmRWSnhPVUpGUWpkbmQwTm5XVWxMYjFwSmVtb3dSVUYzVFhjS1RucEZWazFDVFVkQk1WVkZRMmhOVFdNeWJHNWpNMUoyWTIxVmRWcEhWakpOVWpSM1NFRlpSRlpSVVVSRmVGWjZZVmRrZW1SSE9YbGFVekZ3WW01U2JBcGpiVEZzV2tkc2FHUkhWWGRJYUdOT1RXcE5kMDFVUlhwTlJHTjRUVlJKZVZkb1kwNU5hazEzVFZSRmVrMUVZM2xOVkVsNVYycEJRVTFHYTNkRmQxbElDa3R2V2tsNmFqQkRRVkZaU1V0dldrbDZhakJFUVZGalJGRm5RVVZFVkhaTU1GQlNjM2h2ZUUxWVpsTmhXSFVyTjNjd2IzWldUbnBhYXk5Q1FVbHZlaklLUjB3eVkxQlpNM0ZhUlU1Vkx5dFpjbEk1TWtGMVdrWlliakJxVTIxdGRrOXJkSEJCZWtkb2JrUm9kR2xrYjI1cmVVdFBRMEZWTUhkblowWktUVUUwUndwQk1WVmtSSGRGUWk5M1VVVkJkMGxJWjBSQlZFSm5UbFpJVTFWRlJFUkJTMEpuWjNKQ1owVkdRbEZqUkVGNlFXUkNaMDVXU0ZFMFJVWm5VVlZrV2xCMkNsQmtOV0ZpVFd0WE9HMWpRbWRpTTNWdFFXMUlWR05WZDBoM1dVUldVakJxUWtKbmQwWnZRVlV6T1ZCd2VqRlphMFZhWWpWeFRtcHdTMFpYYVhocE5Ga0tXa1E0ZDBwM1dVUldVakJTUVZGSUwwSkNNSGRITkVWYVdrZEdkV0ZYVm5OTWJVcHNaRzFXZFdGWVZucFJSMlIwV1Zkc2MweHRUblppVkVGelFtZHZjZ3BDWjBWRlFWbFBMMDFCUlVKQ1FqVnZaRWhTZDJONmIzWk1NbVJ3WkVkb01WbHBOV3BpTWpCMllrYzVibUZYTkhaaU1rWXhaRWRuZDJkWmIwZERhWE5IQ2tGUlVVSXhibXREUWtGSlJXWkJValpCU0dkQlpHZEVaRkJVUW5GNGMyTlNUVzFOV2tob2VWcGFlbU5EYjJ0d1pYVk9ORGh5Wml0SWFXNUxRVXg1Ym5VS2FtZEJRVUZaVjNBclFXbFpRVUZCUlVGM1FraE5SVlZEU1VGc1prdzROekJYU25SaE4zQkVPVGRaYVhjd1NtSjJXVGRaUjJjMk1EUmpSM2hZUlZoMFVRcDBlbTloUVdsRlFTdFdWMUZwZWl0S1VFVnpURUpNWW5SamJHWm9XRVpvYmk5RE5HdFVlV0ZUTWtacU1USXJkbTlVZERSM1EyZFpTVXR2V2tsNmFqQkZDa0YzVFVSYWQwRjNXa0ZKZDFWMFFrSXJNVWcyTVRjM1MxY3pibVpVY0VzNWRXNVRSMmQzU1ZCRmRVNXhVWFpwU25sbFdsSnFhMHM0TlhCdVptc3djRFVLYkhkUlZtSm1aV3RZV1hFclFXcENaMHBCTDNocVdEVXJWWEZTYUN0UE1VeHhlRUpKZFc0eFoxbG9TWGRMSzFWVlduRTBPVk5JTUhWUU1uTlJURFYxYmdwSlRFaFBVSEpDZHpCbU1EQlJOamc5Q2kwdExTMHRSVTVFSUVORlVsUkpSa2xEUVZSRkxTMHRMUzBLIn19fX0=",
  "integratedTime": 1673593883,
  "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d",
  "logIndex": 11074687,
  "verification": {
    "inclusionProof": {
      "checkpoint": "rekor.sigstore.dev - 2605736670972794746\n6915767\nIDKYzW3/yaZoFrPpz2HKEReyArFz47FmWC3Z9REfsCY=\nTimestamp: 1673599771028600100\n\n— rekor.sigstore.dev wNI9ajBFAiBcmpywRj3UZCOMIzwlHzd5eNYEG1rQgX5VKhHAqM49iQIhAPxul/hYfn7wHRCh8/LTXFpLbB3vieU4mqLEPZSUdX4L\n",
      "hashes": [
        "e5871beb5d6ffc577b31f4b0f14763adb1a231d52f2f15dd8c44f4925e402d1d",
        "1d2962738aaebe76a8497de8615fadb0b8a52db957ccfb37b87719131abb53bd",
        "62c6f1d6610f123395faffd632dc853f682a7f1bd93e36c08e53f8591b2b50d7",
        "c1bb29369643451e47467ce1293a981ee4bd00a019a0a5bf77dacfd0aa15eff7",
        "fec4c3b5bfb7783f8eee0e83af6e781f49825efb515bd70b2745b4d15b0b56f5",
        "aaee4f535cb2dca6853ab13d2f2eda182dd72aa708824d6281182009763e753e",
        "22430b589e10029a924c4ec50a96b51fa0aff8b461b205dc9e02d3eb588bcd98",
        "067da42bda7c3c476cbd160a7df567266e3c4788d38d214b44774907a1e1bd27",
        "2269e80ae081e893a5e7a6350826b29bdf890afa397110c632910acf895e7a26",
        "7c4a791951a23906049a3060ac3f29e571df225f0d7eadeb5417dff7631c8cec",
        "3648d28ef4842a998b3f22755750e99a81a74d6567166831e325f044cde6162b",
        "0cd1da2cb04f7956568f32c500bad03be8a022faa50f393c185ac5ac201f3339",
        "a14a3e23a363f496dc96a3061d454e1f0629ea94c0664991d4e5eab4d29306cb",
        "4c00279b889607cf1f98294f05dc3f10ffecd2a87df4af3e4360a039ff3421c9",
        "35da85b3d8a823b9040af497f298dc7c517236e78a98b1b426251b9ecde33628",
        "9d57b977c2a8ebeb68d127df7be605c849c732275a0b05db00264a59f4ca0834",
        "9eb0417210c64dcc971f58268b5aaa968ce2c2d200c41b346f50a100728ebc72",
        "e7d67f5102ddeda58eda651dcba76876d01955a4eca9fce4caaf9e0ba7521cdd",
        "616429db6c7d20c5b0eff1a6e512ea57a0734b94ae0bc7c914679463e01a7fba",
        "5a4ad1534b1e770f02bfde0de15008a6971cf1ffbfa963fc9c2a644973a8d2d1"
      ],
      "logIndex": 6911256,
      "rootHash": "203298cd6dffc9a66816b3e9cf61ca1117b202b173e3b166582dd9f5111fb026",
      "treeSize": 6915767
    },
    "signedEntryTimestamp": "MEUCIGicHWGa0XI3perd9LM64+tdneXvvVsOrWxn7pCoUbuNAiEAjmgWIxOH8itbqYjAgkiilYmNVR/hewmfatviQZf3Wr8="
  }
}

The Rekor log can also be accessed using https: https://rekor.tlog.dev/?logIndex=11074687

Now, lets inspect the body field of the bundle:

$ cat artifact.bundle | jq -r '.rekorBundle.Payload.body' | base64 -d - | jq
{
  "apiVersion": "0.0.1",
  "kind": "hashedrekord",
  "spec": {
    "data": {
      "hash": {
        "algorithm": "sha256",
        "value": "5aa03f96c77536579166fba147929626cc3a97960e994057a9d80271a736d10f"
      }
    },
    "signature": {
      "content": "MEUCIBbfVr0rREgk2yXfENMzTduXnSRc2GkJEUOb5tBncFgSAiEAtC4f1CA4Yio9N3wjdMAbY6hCerCKwyM+hn8L1kn33GE=",
      "publicKey": {
        "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNwekNDQWk2Z0F3SUJBZ0lVYjZMRENObHZIblVHRDU1ZGJZdVJxOUJFQjdnd0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpNd01URXpNRGN4TVRJeVdoY05Nak13TVRFek1EY3lNVEl5V2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVEVHZMMFBSc3hveE1YZlNhWHUrN3cwb3ZWTnpaay9CQUlvejIKR0wyY1BZM3FaRU5VLytZclI5MkF1WkZYbjBqU21tdk9rdHBBekdobkRodGlkb25reUtPQ0FVMHdnZ0ZKTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVVkWlB2ClBkNWFiTWtXOG1jQmdiM3VtQW1IVGNVd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d0p3WURWUjBSQVFIL0JCMHdHNEVaWkdGdWFXVnNMbUpsZG1WdWFYVnpRR2R0WVdsc0xtTnZiVEFzQmdvcgpCZ0VFQVlPL01BRUJCQjVvZEhSd2N6b3ZMMmRwZEdoMVlpNWpiMjB2Ykc5bmFXNHZiMkYxZEdnd2dZb0dDaXNHCkFRUUIxbmtDQkFJRWZBUjZBSGdBZGdEZFBUQnF4c2NSTW1NWkhoeVpaemNDb2twZXVONDhyZitIaW5LQUx5bnUKamdBQUFZV3ArQWlZQUFBRUF3QkhNRVVDSUFsZkw4NzBXSnRhN3BEOTdZaXcwSmJ2WTdZR2c2MDRjR3hYRVh0UQp0em9hQWlFQStWV1FpeitKUEVzTEJMYnRjbGZoWEZobi9DNGtUeWFTMkZqMTIrdm9UdDR3Q2dZSUtvWkl6ajBFCkF3TURad0F3WkFJd1V0QkIrMUg2MTc3S1czbmZUcEs5dW5TR2d3SVBFdU5xUXZpSnllWlJqa0s4NXBuZmswcDUKbHdRVmJmZWtYWXErQWpCZ0pBL3hqWDUrVXFSaCtPMUxxeEJJdW4xZ1loSXdLK1VVWnE0OVNIMHVQMnNRTDV1bgpJTEhPUHJCdzBmMDBRNjg9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
      }
    }
  }
}

Now, when an online verification is done, that is when the bundle is not specified on the command line, the Rekor bundle is looked up in the transparency log. Notice for example that the same information is also available in the Rekor log:

$ curl --silent https://rekor.sigstore.dev/api/v1/log/entries?logIndex=11074687 | jq -r '.[].body' | base64 -d | jq
{
  "apiVersion": "0.0.1",
  "kind": "hashedrekord",
  "spec": {
    "data": {
      "hash": {
        "algorithm": "sha256",
        "value": "5aa03f96c77536579166fba147929626cc3a97960e994057a9d80271a736d10f"
      }
    },
    "signature": {
      "content": "MEUCIBbfVr0rREgk2yXfENMzTduXnSRc2GkJEUOb5tBncFgSAiEAtC4f1CA4Yio9N3wjdMAbY6hCerCKwyM+hn8L1kn33GE=",
      "publicKey": {
        "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNwekNDQWk2Z0F3SUJBZ0lVYjZMRENObHZIblVHRDU1ZGJZdVJxOUJFQjdnd0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpNd01URXpNRGN4TVRJeVdoY05Nak13TVRFek1EY3lNVEl5V2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVEVHZMMFBSc3hveE1YZlNhWHUrN3cwb3ZWTnpaay9CQUlvejIKR0wyY1BZM3FaRU5VLytZclI5MkF1WkZYbjBqU21tdk9rdHBBekdobkRodGlkb25reUtPQ0FVMHdnZ0ZKTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVVkWlB2ClBkNWFiTWtXOG1jQmdiM3VtQW1IVGNVd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d0p3WURWUjBSQVFIL0JCMHdHNEVaWkdGdWFXVnNMbUpsZG1WdWFYVnpRR2R0WVdsc0xtTnZiVEFzQmdvcgpCZ0VFQVlPL01BRUJCQjVvZEhSd2N6b3ZMMmRwZEdoMVlpNWpiMjB2Ykc5bmFXNHZiMkYxZEdnd2dZb0dDaXNHCkFRUUIxbmtDQkFJRWZBUjZBSGdBZGdEZFBUQnF4c2NSTW1NWkhoeVpaemNDb2twZXVONDhyZitIaW5LQUx5bnUKamdBQUFZV3ArQWlZQUFBRUF3QkhNRVVDSUFsZkw4NzBXSnRhN3BEOTdZaXcwSmJ2WTdZR2c2MDRjR3hYRVh0UQp0em9hQWlFQStWV1FpeitKUEVzTEJMYnRjbGZoWEZobi9DNGtUeWFTMkZqMTIrdm9UdDR3Q2dZSUtvWkl6ajBFCkF3TURad0F3WkFJd1V0QkIrMUg2MTc3S1czbmZUcEs5dW5TR2d3SVBFdU5xUXZpSnllWlJqa0s4NXBuZmswcDUKbHdRVmJmZWtYWXErQWpCZ0pBL3hqWDUrVXFSaCtPMUxxeEJJdW4xZ1loSXdLK1VVWnE0OVNIMHVQMnNRTDV1bgpJTEhPUHJCdzBmMDBRNjg9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
      }
    }
  }
}

Now, let first look at the spec.data.hash field which contains a hash algorithm that was used, and a value. The value is the hash of our blob, the artifact.txtfile:

$ sha256sum artifact.txt
5aa03f96c77536579166fba147929626cc3a97960e994057a9d80271a736d10f  artifact.txt

And we can compare this with the value in the spec.data.hash.value field and check that they indeed are the same:

$ cat artifact.bundle | jq -r '.rekorBundle.Payload.body' | base64 -d - | jq -r '.spec.data.hash.value'
5aa03f96c77536579166fba147929626cc3a97960e994057a9d80271a736d10f

Next we have signature field:

$ cat artifact.bundle | jq -r '.rekorBundle.Payload.body' | base64 -d - | jq -r '.spec.signature.content'
MEUCIBbfVr0rREgk2yXfENMzTduXnSRc2GkJEUOb5tBncFgSAiEAtC4f1CA4Yio9N3wjdMAbY6hCerCKwyM+hn8L1kn33GE=

Notice that this is the same value as the toplevel base64Signature field:

$ cat artifact.bundle | jq -r '.base64Signature'
MEUCIBbfVr0rREgk2yXfENMzTduXnSRc2GkJEUOb5tBncFgSAiEAtC4f1CA4Yio9N3wjdMAbY6hCerCKwyM+hn8L1kn33GE=

And there is also a publicKey field in the body which contains:

$ cat artifact.bundle | jq -r '.rekorBundle.Payload.body' | base64 -d - | jq -r '.spec.signature.publicKey.content' | base64 -d
-----BEGIN CERTIFICATE-----
MIICpzCCAi6gAwIBAgIUb6LDCNlvHnUGD55dbYuRq9BEB7gwCgYIKoZIzj0EAwMw
NzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl
cm1lZGlhdGUwHhcNMjMwMTEzMDcxMTIyWhcNMjMwMTEzMDcyMTIyWjAAMFkwEwYH
KoZIzj0CAQYIKoZIzj0DAQcDQgAEDTvL0PRsxoxMXfSaXu+7w0ovVNzZk/BAIoz2
GL2cPY3qZENU/+YrR92AuZFXn0jSmmvOktpAzGhnDhtidonkyKOCAU0wggFJMA4G
A1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUdZPv
Pd5abMkW8mcBgb3umAmHTcUwHwYDVR0jBBgwFoAU39Ppz1YkEZb5qNjpKFWixi4Y
ZD8wJwYDVR0RAQH/BB0wG4EZZGFuaWVsLmJldmVuaXVzQGdtYWlsLmNvbTAsBgor
BgEEAYO/MAEBBB5odHRwczovL2dpdGh1Yi5jb20vbG9naW4vb2F1dGgwgYoGCisG
AQQB1nkCBAIEfAR6AHgAdgDdPTBqxscRMmMZHhyZZzcCokpeuN48rf+HinKALynu
jgAAAYWp+AiYAAAEAwBHMEUCIAlfL870WJta7pD97Yiw0JbvY7YGg604cGxXEXtQ
tzoaAiEA+VWQiz+JPEsLBLbtclfhXFhn/C4kTyaS2Fj12+voTt4wCgYIKoZIzj0E
AwMDZwAwZAIwUtBB+1H6177KW3nfTpK9unSGgwIPEuNqQviJyeZRjkK85pnfk0p5
lwQVbfekXYq+AjBgJA/xjX5+UqRh+O1LqxBIun1gYhIwK+UUZq49SH0uP2sQL5un
ILHOPrBw0f00Q68=
-----END CERTIFICATE-----

Notice that this is the same certificate as the toplevel cert field. Using the base64Signature field, and the cert field we are able to verify a blob which we saw an example of previously.

Hopefully this has given some insight into the bundle format and given some example of how one can inspect the fields.

Sigstore, in-toto, OPA, orientation

2023-01-11T00:00:00.000Z

As someone who was completly new to secure supply chain security (sscs) there were a lot of new projects that I learned the names of but did not really understand exactly what they did or how they complement each other. This post hopes to clarify a few of these projects, and others will be addressed in future posts.

Lets say we have a software project that we want to distribute. We want to sign the artifact that we produce, and lets say it's distributed as a tar file. It is possible to do this signing manually, but it involves some work like managing keys and using tools to perform the signing tasks. Using sigstore simplfies this process, similar to how Let's Encrypt made it simpler to get certificates to be used with web sites. Sigstore also provides tools to verify signatures and a transparency log to store signatures. So that allows us to sign our end product, and publish the signatures to the transparency log, and consumers/clients can verify our artifact.

But how can we trust what was built? For example, if I built this tar on my local laptop I could replace a source code file with a backdoor and still be able to produce a valid signature, and it could still be verified. This is also the case if a build server is used and it gets compromised, so we need something more.

This is where another project named in-toto comes into play. It contains tools to define the steps of a build process, and assign someone that is responsible for each step. This person also signs the artifact produced by that step. So each step is signed by the person responsible for that step, called the funtionary, and then all the steps are signed by a product owner. This will produce a document which lists the steps that were followed to produce the software, with signatures for each step.

For example, one step might have been checking out a specific version from git, and this could be verified that it was indeed that version that was used, and the source files that were used. This gives the end user insight into the product that they are about to install and the ability to verify it.

So we now have our built artifact, signed it, and we have attestations, in this case json files that contain metadata about how it was built. And we can use in-toto-verify to verify that all that information is correct.

Now, lets say that another company, or another project, wants to include our software in their project, as a thirdparty dependency. Ours might be one of many dependencies that they include in their product and they might have requirements/restrictions on what they are allowed to use. For example, they might require that only certain licences are used. The license information is hopefully available in the project, like a license file or field in Cargo.toml, but there is nothing available to say that only certain licenses are allowed. This is where a policy engine like Open Policy Agent (OPA) comes into play. OPA gives us the ability to write policy rules that take in-toto json files as input, and verify that there are licences for all thirdparty dependencies and that they are of the type(s) that are allowed. Rules can be written to handle other types of restrictions/requirements as well, which are the policies that the company has.

So they could include a step in their build process that execute enforces the policy rules they have defined. Policy rules can also be useful when deploying applications in container images where one might want to make sure that only supported base images are used etc.

Hopefully this post gives some insight into how Sigstore, in-toto, and OPA may be used, and how they complement each other.

An Adventure with the CycloneDX Maven Plugin

2022-12-09T00:00:00.000Z

The CycloneDX Maven Plugin can be used to generate CycloneDX Software Bill of Materials (SBOM) for your maven projects as part of your build process. The plugin is easy to integrate, however does have some issues due mostly to idiosyncrasies and shortcomings with the maven resolution mechanism. In this post I attempt to provide some background, examples and explanations for the issues I've discovered as well as context for the solutions I'm proposing.

Three weeks ago I started an adventure with the CycloneDX Maven Plugin, investigating how we could make use of this plugin to generate Software Bill of Materials (SBOMs) for the Quarkus project. At first this goal appeared easy to achieve, simply enable the plugin for all projects within the Quarkus build (hello parent pom.xml) and verify the generated bom contents were accurate.

As I had expected, enabling the plugin was very straight forward. I created a profile in the top level pom.xml to capture the information required at compile time, incorporating all artifacts using compile, provided and system maven scopes. I chose not to include any test or runtime artifacts.

Once the BOM files were created I looked for a way to verify the output was reasonable. I turned to the maven dependency plugin and its tree goal, along with a fairly straight forward script to compare the information in the generated dependency tree with that in the bom file and highlight any discrepancies. This is where the fun began 😁

The remainder of those three weeks involved many hours with a debugger, walking through the internals of maven as well as the CycloneDX plugin, identifying the causes of these discrepancies and working through fixes to generate the output I believed should have been included in the bom files.

Note: At this time these changes have neither been discussed nor reviewed by the CycloneDX community, I've reached out to them via slack and am hoping we can find time to go through this in detail over the next few weeks or so. In the meantime treat this article as my opinions of what I believe should be done.

Part Two - The Case of the Missing Dependency

Before we talk about missing dependencies we first need to take a quick refresher for how maven resolves artifacts within a project.

One of the benefits of maven is its ability to automatically derive the dependency tree for your project using the information in your pom.xml combined with the information in the pom.xml for each of your transitive dependencies. Maven will take this information and create a dependency tree where each artifact exists once (not always the case, but we will come on to that), will favour artifacts which are closer to the root of the tree than those farther away, reconcile their versions based on the defined constraints and derive an appropriate scope.

The example used in the maven documentation is as follows

A
  ├── B
  │   └── C
  │       └── D 2.0
  └── E
      └── D 1.0

As the shortest path to D is via E, the generated dependency tree will look like

A
  ├── B
  │   └── C
  └── E
      └── D 1.0

With the above refresher out of the way let's move on to the issue of missing dependencies and consider the following example

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- com.example:dependency2:jar:1.0.0:compile
|     \- com.example:shared_dependency1:jar:1.0.0:compile
|       \- com.example:shared_dependency2:jar:1.0.0:compile
\- com.example:test_dependency:jar:1.0.0:test
   \- com.example:shared_dependency1:jar:1.0.0:compile
      \- com.example:shared_dependency2:jar:1.0.0:compile

In this graph we can see that com.example:dependency2 and com.example:test_dependency both depend on com.example:shared_dependency1, with dependency2 having a scope of compile and test_dependency having a scope of test. When this graph is processed by maven we end up with a dependency tree which is close to the example given in the maven documentation.

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- com.example:dependency2:jar:1.0.0:compile
\- com.example:test_dependency:jar:1.0.0:test
   \- com.example:shared_dependency1:jar:1.0.0:compile
      \- com.example:shared_dependency2:jar:1.0.0:compile

Each artifact exists once and the shared_dependency1 artifact is now seen only under the test_dependency artifact.

Only this isn't the full picture.

What is actually taking place under the covers is that each set of conflicts within the graph is being evaluated in order to decide which one is chosen (the winning artifact), with all losing artifacts then being updated and turned into a marker artifact without child dependencies. We can see a visualisation of this by enabling the verbose flag on the dependency:tree goal (use version 3.4.0), which displays the underlying dependency tree and not the clean version.

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- com.example:dependency2:jar:1.0.0:compile
|     \- (com.example:shared_dependency1:jar:1.0.0:compile - omitted for duplicate)
\- com.example:test_dependency:jar:1.0.0:test
   \- com.example:shared_dependency1:jar:1.0.0:compile (scope not updated to compile)
      \- com.example:shared_dependency2:jar:1.0.0:compile

We can now see that the shared_dependency1 artifact exists multiple times and that the dependency under dependency2 lost the conflict resolution to the dependency under test_dependency.

How do we end up with missing dependencies? This happens when we filter the graph using scopes, which in my case includes compile, provided and system. Let's take a look at what happens under those circumstances.

Maven's DependencyCollectorBuilder works by first generating the dependency tree, with conflicts resolved as above, then pruning the result to remove subtrees which are not accepted by the filter. In my case this means any artifacts which do not have the right scope, along with their dependent children, will be removed. The tree returned to the CycloneDX plugin will be as follows

com.example:trustification:jar:1.0.0
\- com.example:dependency1:jar:1.0.0:compile
   \- com.example:dependency2:jar:1.0.0:compile
      \- (com.example:shared_dependency1:jar:1.0.0:compile - omitted for duplicate)

The CycloneDX plugin will process this tree and create the following dependency graph within the bom file

This is notable for two reasons

The bom contains the shared_dependency1 artifact even though this entry came from the marker entry (we can make use of this)
We have lost the shared_dependency2 artifact since it is only present under the pruned test scoped subtree.

In order to see a representation of the graph I would like in the bom we simply need to comment out the test dependency in the top level pom.xml, which would result in the following dependency tree

com.example:trustification:jar:1.0.0
\- com.example:dependency1:jar:1.0.0:compile
   \- com.example:dependency2:jar:1.0.0:compile
      \- com.example:shared_dependency1:jar:1.0.0:compile
         \- com.example:shared_dependency2:jar:1.0.0:compile

and the following dependency graph in the bom

How can we fix this while including the test artifact as a dependency? We can rely on the following information

the marker artifact has been included in the filtered result tree, however it is without children
the full dependency tree contains a winner artifact which contains any dependent children

We can then follow this process

retrieve the full dependency tree
collect all children from top level test scoped dependencies
search the original tree looking for potential marker artifacts, i.e. those without children, then
- check the set of hidden artifacts to see if the potential marker artifact is also hidden
- if the hidden artifact does exist then transplant its dependencies to the marker artifact

The above will allow us to reconstruct the missing parts of the SBOM dependency graph and create my desired bom content.

Note: The same issue will occur with runtime scoped artifacts within the graph, these can also conceal compile scoped artifacts if closer to the root. The difference between test scoped artifacts and those with runtime scope is that the runtime scoped artifacts can exist anywhere in the dependency tree whereas the test artifacts will only be found at the top level. The runtime artifacts can be handled by following a similar process to the one above, extended to the full dependency tree.

Part Three - Should Consistency Matter?

In going through the bom file we can see that the information is split into two major types, Components and Dependencies. My expectation was that this information would be consistent, with these elements being related as follows

each Dependency being associated with a Component
each nested Dependency referencing an existing top level Dependency element
each Component being associated with a top level Dependency

One of the verification tests I ran on the bom files was to test these expectations, and while I did not discover any issues with the Dependencies I did discover numerous examples of Components existing without any associated dependency information.

We can revisit the example from earlier to explain why this happens. The CycloneDX code decides which components to include based on the set of resolved artifacts derived from the full dependency tree, and it does this separately from determining the filtered dependency graph. The only connection between the two is that, when generating the dependency graph, the existing process will check whether the dependency has an associated Component before adding it to the graph. If the Component has not been created then the dependency will be ignored.

As a reminder, here's the example we covered earlier as seen by CycloneDX when processing the dependency graph.

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- com.example:dependency2:jar:1.0.0:compile
|     \- (com.example:shared_dependency1:jar:1.0.0:compile - omitted for duplicate)
\- com.example:test_dependency:jar:1.0.0:test
   \- com.example:shared_dependency1:jar:1.0.0:compile (scope not updated to compile)
      \- com.example:shared_dependency2:jar:1.0.0:compile

And the following represents the set of resolved artifacts used to determine which Components and Dependencies are included in the SBOM dependency graph, assuming we are generating the bom based on the compile scope.

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- com.example:dependency2:jar:1.0.0:compile
\- 
   \- com.example:shared_dependency1:jar:1.0.0:compile (scope not updated to compile)
      \- com.example:shared_dependency2:jar:1.0.0:compile

There are two issues with this that I can see

this will generate Components for all compile scope artifacts in the tree, including shared_dependency2 from the test subtree
this ignores the cumulative scopes used by maven when filtering the artifacts to create the dependency tree, relying instead on an explicit test of equality

All of the instances I have discovered so far have been related to the missing dependency issue from Part Two, and are addressed by ensuring concealed artifacts are included in the SBOM dependency graph, however I am not yet convinced this is the only circumstance under which this would occur with the current codebase.

Note: The Maven cumulative scopes are as follows

compile -> system, provided and compile
runtime -> compile and runtime
test -> system, provided, compile, runtime and test

Another related issue, coupled with the processing of excluded types, is the possibility of creating split dependency graphs within the same SBOM.

Consider the following dependency tree

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- com.example:dependency2:jar:1.0.0:compile
\- com.example:type_dependency:test-jar:tests:1.0.0:compile
   \- com.example:shared_type_dependency1:jar:1.0.0:compile
      \- com.example:shared_type_dependency2:jar:1.0.0:compile

If we create the SBOM for the above tree, and choose to exclude artifacts of type test-jar from the graph, the current approach will result in two dependency graphs being generated. The first would be rooted at com.example:trustification and the second would be rooted at com.example:shared_type_dependency1. This is another consequence of the Component creation process, since only the specific com.example:type_dependency:test-jar artifact will be removed from the graph and not its dependencies. This results in the following dependency section within the bom.

If we move the processing of the excluded types to the creation of the SBOM dependency graph we could address this issue and create only a single dependency graph for the root artifact, however without also addressing how we determine which Components are included in the bom we would be creating another source for inconsistencies and those now excluded artifacts would still exist in the Components section.

I believe a better approach would be to start with the assumption that all artifacts are included as Components, generate the dependency graph with type exclusion, and then prune all unreferenced components from the generated bom. Please remember this for now, it will come up again in the next part.

Part Four - The Return of the Missing Dependency

In Part Two we discussed what happened when the dependency resolution led to parts of the dependency tree being concealed by artifacts with test or runtime scopes, however one edge case we did not cover is when the dependency is itself the test scoped artifact. In the current CycloneDX implementation this will cause the test artifact, and its children, to be ignored because of the mechanism used to determine which Components are included in the bom. Recall from Part Three that dependencies will not be included in the dependency graph unless they already have an associated Component.

We can show this in action by looking at a modified version of the earlier example, depicted by dependency:tree as follows

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- (com.example:test_dependency:jar:1.0.0:compile - omitted for duplicate)
\- com.example:test_dependency:jar:1.0.0:test (scope not updated to compile)
   \- com.example:shared_dependency1:jar:1.0.0:test
      \- com.example:shared_dependency2:jar:1.0.0:test

One fact we should be aware of is that the only real test scoped artifacts in the tree will be at the top level, Maven will ignore lower level test scoped artifacts when determining the transitive graph. In this case test_dependency is the only true test scoped artifact, and as neither shared_dependency1 not shared_dependency2 are referenced from a compile scope they only have a scope of test by inheriting it from the parent. Compare this with the example we used previously, when shared_dependency1 was referenced from a compile scope.

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- com.example:dependency2:jar:1.0.0:compile
|     \- (com.example:shared_dependency1:jar:1.0.0:compile - omitted for duplicate)
\- com.example:test_dependency:jar:1.0.0:test
   \- com.example:shared_dependency1:jar:1.0.0:compile (scope not updated to compile)
      \- com.example:shared_dependency2:jar:1.0.0:compile

What I would like to see is the SBOM dependency graph represented as follows

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0
   \- com.example:test_dependency:jar:1.0.0
      \- com.example:shared_dependency1:jar:1.0.0
         \- com.example:shared_dependency2:jar:1.0.0

This can be fixed by following a similar process to that discussed in Part Two, however it will also require us to move away from the current mechanism of identifying Components and relying on those references to restrict which Artifacts can be included in the dependency graph. Instead of the existing mechanism we would start from the assumption that all Artifacts will be included, determine the actual dependency graph, and then use this to prune the set of Components down to the required set.

Once this switch is made we can finally include those remaining missing dependencies in the graph and address the issues from Part Three, we certainly have a number of reasons for doing so.

There are a few implementation details we do need to be aware of when switching approaches

we need to consider excluded types, as moving their processing to the creation of the dependency graph will allow us to correctly handle their subtrees, however they can now also conceal parts of the dependency graph
we need to ensure we do not inadvertently pull in runtime scoped artifacts when reconstructing the graph from concealed dependencies

Conclusions

This has been an interesting journey, and through it I've learned a lot about CycloneDX and more than I had likely wanted to know about the implementation of Maven. I have addressed all of the issues I believe to be present with the current approach, with the exception of one. While it is true that we can reconstruct the dependency tree to include concealed artifacts, the information provided directly by maven is insufficient to resolve all cases. The edge case identified in Part Four covers the inclusion of compile scoped artifacts which are referenced through a top level test artifact, however there is also the case of runtime artifacts being included which, unfortunately, also have their scopes modified to a test scope.

By way of example, if we were to change the scope of the shared_dependency1 dependency within the test_dependency pom.xml to a scope of runtime we would still see the following returned by maven

com.example:trustification:jar:1.0.0
+- com.example:dependency1:jar:1.0.0:compile
|  \- (com.example:test_dependency:jar:1.0.0:compile - omitted for duplicate)
\- com.example:test_dependency:jar:1.0.0:test (scope not updated to compile)
   \- com.example:shared_dependency1:jar:1.0.0:test
      \- com.example:shared_dependency2:jar:1.0.0:test

As things currently stand we now have a bom file which is no longer missing dependencies, although it may include the occasional runtime scoped artifact when it really shouldn't. In order to fix this edge case we will need to go deeper into the maven level and look at the underlying graph generated by Eclipse Aether as this contains more useful information.

Node: com.example:trustification:1.0.0    {}
  Node: com.example:dependency1:1.0.0    {conflict.originalScope=compile, conflict.originalOptionality=false}
    Node: com.example:test_dependency:1.0.0    {conflict.winner=com.example:test_dependency:jar:1.0.0 (test), conflict.originalScope=compile, conflict.originalOptionality=false}
  Node: com.example:test_dependency:1.0.0    {REDUCED_SCOPE=compile, conflict.originalScope=test, conflict.originalOptionality=false}
    Node: com.example:shared_dependency1:1.0.0    {conflict.originalScope=runtime, conflict.originalOptionality=false}
      Node: com.example:shared_dependency2:1.0.0    {conflict.originalScope=compile, conflict.originalOptionality=false}

The above information contains the original scope of the dependencies, the optionality and also a reference to the winning dependency in the case of conflict.

Switching over to using this tree would likely be intrusive, and not something I would like to do without building up the existing test cases within the project. This is definitely a task for another day 😁

How to Configure a Gitsign Cache

2022-12-05T00:00:00.000Z

This post contains the steps for setting up gitsign-credential-cache. which is useful if one has to perform multiple commits in short succession, or when doing a rebase.

It can be somewhat frustrating to have the browser open for every single commit. For these situations a cache can be enabled using the instructions in this post.

First install gitsign-credential-cache if it is not already installed:

$ go install github.com/sigstore/gitsign/cmd/gitsign-credential-cache@latest

Create a file named ~/.config/systemd/user/gitsign.service:

[Unit]
Description=Gitsign Credentials Cache
Documentation=https://github.com/sigstore/gitsign

[Service]
Type=simple
ExecStart=%h/go/bin/gitsign-credential-cache

Restart=on-failure

[Install]
WantedBy=default.target

This service can then be enabled using:

$ systemctl --user daemon-reload
$ systemctl --user enable gitsign.service
Created symlink /home/danielbevenius/.config/systemd/user/default.target.wants/gitsign.service → /home/danielbevenius/.config/systemd/user/gitsign.service.

And we can start it manually using:

$ systemctl --user start gitsign.service

Check that it has started successfully:

$ systemctl --user status gitsign.service
● gitsign.service - Gitsign Credentials Cache
     Loaded: loaded (/home/danielbevenius/.config/systemd/user/gitsign.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2022-11-28 11:27:47 CET; 2min 35s ago
       Docs: https://github.com/sigstore/gitsign
   Main PID: 177444 (gitsign-credent)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gitsign.service
             └─ 177444 /home/danielbevenius/go/bin/gitsign-credential-cache

Nov 28 11:27:47 localhost.localdomain systemd[1295]: Started Gitsign Credentials Cache.
Nov 28 11:27:47 localhost.localdomain gitsign-credential-cache[177444]: /home/danielbevenius/.cache/.sigstore/gitsig>

And we then need to add the following environment variable:

$ export GITSIGN_CREDENTIAL_CACHE=~/.cache/.sigstore/gitsign/cache.sock

After this we should be able to commit a first time and have our credentials stored. Subsequent commits will then be made without a browser "popup".

Keyless Git Signing with Sigstore

2022-12-02T00:00:00.000Z

This post contains the steps for setting up gitsign to sign your git commits using sigstore.

Install gitsign

$ go install github.com/sigstore/gitsign@latest

Or using brew:

$ brew install sigstore/tap/gitsign

Configure git

The collowing will configure signing for the current project:

#!/bin/bash

# Sign all commits
git config --local commit.gpgsign true

# Sign all tags
git config --local tag.gpgsign true

# Use gitsign for signing
git config --local gpg.x509.program gitsign

# gitsign expects x509 args
git config --local gpg.format x509

To configure for all projects, use:

#!/bin/bash

# Sign all commits
git config --global commit.gpgsign true

# Sign all tags
git config --global tag.gpgsign true

# Use gitsign for signing
git config --global gpg.x509.program gitsign

# gitsign expects x509 args
git config --global gpg.format x509

Commit

Now when you commit, gitsign will be used to start an Open ID Connect (OIDC) flow. This will allow you to choose an OIDC provider:

$ git commit -v
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=eQvdw56pTgXnkj76Cab-4ZWaKk8XFM6UFFBdayKQX1Y&code_challenge_method=S256&nonce=2GmBDq86TMNuz8VhMUixMxiPSe2&redirect_uri=http%3A%2F%2Flocalhost%3A39617%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2GmBDlYDps5Ywd8dX4Ebwo4VnQL
[master 4292869] Add initial Oniro notes
 1 file changed, 10 insertions(+)
 create mode 100644 notes/oniro.md

Note that on github this commit will be marked as Unverified because the sigstore Certificate Authority root is not part of Github's trust root. Further, validation needs to be done using Rekor to verify that the certificate was valid at the time this commit was signed.

To avoid having to choose an auth provider each time, set the following environment variable. For example:

$ export GITSIGN_CONNECTOR_ID=https://github.com/login/oauth

Verifying a commit

$ git verify-commit HEAD

If verified, you'll see output similar to this:

tlog index: 6058402
gitsign: Signature made using certificate ID 0xb073e00bfabd4fb9988b9e1e0896dcfc1527fcdb | CN=sigstore-intermediate,O=sigstore.dev
gitsign: Good signature from [daniel.bevenius@gmail.com]
Validated Git signature: true
Validated Rekor entry: true

Inspect commit signature

$ git cat-file commit HEAD \
  | sed -n '/BEGIN/, /END/p' \
  | sed 's/^ //g' \
  | sed 's/gpgsig //g' \
  | sed 's/SIGNED MESSAGE/PKCS7/g' \
  | openssl pkcs7 -print -print_certs -text

Welcome

2022-11-30T00:00:00.000Z

Today, we're excited to announce the launch of Trustification, a new community dedicated to improving software supply-chain security.

Trustification Blog

Trustify: Release 0.3.2

The past year​

New and noteworthy​

What's next?​

Trustify: Release 0.1.0-alpha.10

New and noteworthy​

What's next?​

Trying out Trustify, on a local machine

What to expect?​

What do you need?​

Everything, Everywhere, All at once​

Now what?​

So?​

What's next?​

The CycloneDX Maven Aggregate SBOM and why you shouldn't trust it (yet)

What do we get from the current aggregate SBOM?

Differing Sets of Dependencies

Differing Order of Dependencies

Non Transitive Dependencies

Summarising the issue​

How can we solve this?​

Conclusions

in-toto attestations

Signing elf binaries, or not?! Lessons learned.

SBOMs​

What really goes in​

Null and void​

Usability​

Back to binaries​

Solvable downsides​

Too good to be true?​

Happy end?​

So what?​

Footnotes​

Continuing the Adventure with the CycloneDX Maven Plugin

Comparing Upstream Output with my pull request

Identity, Does it Matter?

A look at Guava​

A look at commons-lang3​

A look at jquery​

A look at commons-io​

Summarising the issues​

Now for the solution​

Recap and Solution for guava​

Recap and Solution for commons-lang3​

Recap and Solution for jquery​

Recap and Solution for commons-io​

Conclusions

The Update Framework (TUF)

Root Metadata​

Root metadata​

Targets metadata​

Snapshot metadata​

Timestamp metadata​

Signing root.json​

Generate the TUF repository​

TUF client/consumer​

TUF usage in Sigstore​

Is this a cryptographic key which I see before me?

PEM formatted keys​

DER formatted keys​

When the guidelines fail​

Sigstore bundle format

Sigstore, in-toto, OPA, orientation

An Adventure with the CycloneDX Maven Plugin

Part Two - The Case of the Missing Dependency

Part Three - Should Consistency Matter?

Part Four - The Return of the Missing Dependency

Conclusions

How to Configure a Gitsign Cache

Keyless Git Signing with Sigstore

Install gitsign​

Configure git​

Commit​

Verifying a commit​

Inspect commit signature​

Welcome

The past year

New and noteworthy

What's next?

New and noteworthy

What's next?

What to expect?

What do you need?

Everything, Everywhere, All at once

Now what?

So?

What's next?

Summarising the issue

How can we solve this?

SBOMs

What really goes in

Null and void

Usability

Back to binaries

Solvable downsides

Too good to be true?

Happy end?

So what?

Footnotes

A look at Guava

A look at commons-lang3

A look at jquery

A look at commons-io

Summarising the issues

Now for the solution

Recap and Solution for guava

Recap and Solution for commons-lang3

Recap and Solution for jquery

Recap and Solution for commons-io

Root Metadata

Root metadata

Targets metadata

Snapshot metadata

Timestamp metadata

Signing root.json

Generate the TUF repository

TUF client/consumer

TUF usage in Sigstore

PEM formatted keys

DER formatted keys

When the guidelines fail

Install gitsign

Configure git

Commit

Verifying a commit

Inspect commit signature