# sigstore: the shared Go library behind Fulcio, Rekor, Cosign and Gitsign

> The sigstore repository holds the code that Sigstore's own infrastructure and its Go clients share, which today means a signing interface, an OpenID Connect Fulcio client and a set of KMS integrations. It is a library rather than a product, and its dependency list is where the design decisions are visible.

**sigstore/sigstore** — Common go library shared across sigstore services and clients

- Repository: https://github.com/sigstore/sigstore
- Website: https://sigstore.dev
- Stars: 539 · Forks: 162
- Language: Go
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/sigstore-sigstore

## One library, four consumers

sigstore/sigstore contains common Sigstore code, which is to say code shared by infrastructure and by Go language clients. The README names both sides: infrastructure such as Fulcio and Rekor, and clients such as Cosign and Gitsign.

That positioning explains the shape of the repository. It is not a command line tool and it is not a service. It is the layer that the other four depend on, so the interesting questions are what it contains and how it is organised.

What it currently provides is short. A signing interface, with support for ecdsa, ed25519, rsa and DSSE for in-toto. And OpenID Connect Fulcio client code.

The dependency list is where the design shows. There is go-jose for the JOSE layer, tink-crypto for the primitives, coreos go-oidc for the OpenID Connect side, theupdateframework go-tuf for the TUF metadata handling, secure-systems-lab go-securesystemslib for the in-toto and transparency log primitives, sigstore protobuf-specs for the generated types, and google go-containerregistry for the container image handling. There is also a browser driver, go-rod, and a pkcs8 helper, which is the part that reads a private key from a file in the format you actually have.

The module itself is minimal at the top:

```toml
module github.com/sigstore/sigstore

go 1.27
```

The project is Apache-2.0 licensed, the primary language is Go, the default branch is main, and the last push was on 2026-10-20. The release history is v1.11.1 from 2026-10-14, v1.11.0 from 2026-09-21 and v1.10.10 from 2026-09-10, so this is a project on a steady monthly cadence.

## The signing interface and the KMS matrix

Two things in the library matter most in practice, and they are the signing interface and the key management support.

The signing interface covers ecdsa, ed25519 and rsa, plus DSSE for in-toto, which is the format in-toto uses for its attestations. The point of an interface here is that a caller can ask for a signature without caring whether the key lives in a local file, in a cloud KMS or behind a hardware module, and the implementation behind that request changes.

The KMS list in the README is the catalogue of where a key can actually live. AWS Key Management Service, Azure Key Vault, HashiCorp Vault, Google Cloud Platform Key Management Service, OpenBao, and OVHcloud KMS, which is marked as an external plugin. OpenBao on that list is the open source fork of Vault after the licence change, and having both in the same list is a deliberate choice rather than an oversight.

The external plugin marker matters because it tells you how a new provider is meant to be added. A provider that lives in the tree is built with the library; a provider that does not is a separate binary that plugs in. The repository layout shows the in-tree ones under pkg/signature/kms, with directories for aws, azure, gcp and hashivault, and a cliplugin directory for the external case, alongside a test directory for a local KMS used in tests.

That structure is why the Makefile treats the tree as several Go modules rather than one. The KMS providers and the test helpers have their own go.mod files, which lets a user pull the module for the one provider they need without pulling every provider's SDK.

## The Makefile shows a multi-module repository, not one Go module

The build file is the clearest evidence of the multi-module layout, and it is worth reading because it explains what you get when you depend on this library.

The GO_MOD_DIRS variable lists the directories that are built as separate modules: the root, then the aws, azure, gcp and hashivault KMS packages, then the cliplugin directory, the fuzz directory and the tools directory under hack.

The pkg target builds each of them in turn with CGO_ENABLED=0 and -trimpath, passing the link flags through. CGO_ENABLED=0 means the result is a static binary, and -trimpath strips local filesystem paths out of the binary, which is the right thing to do when you are shipping build artefacts. The lint target does the same walk with golangci-lint, using --new-from-rev to only report issues on new code.

The fuzz and test targets point at the same directories. The fuzz directory is ./test/fuzz, the integration test directory is ./test/e2e, and there is a local KMS test binary built into ./bin with the name sigstore-kms-testkms, and a Windows variant of that name when the build is running on Windows. The path is extended with that binary directory so the tests can find it.

The default target is all, which is pkg and fuzz. So a full build runs the package build and the fuzzing setup, and the Makefile help lists the whole set: all, pkg, test, test-e2e, test-signer-program, clean, lint, fuzz and help.

For a library user, the practical takeaway is that depending on the root module gives you the shared pieces, and the provider packages are separate modules you can pull individually.

## Fuzzing, and the retraction to notice

Two things in the repository are worth a closer look before you pin a version.

The first is the fuzzing. There is a fuzzing status badge in the README pointing at the oss-fuzz project, so the library is fuzzed continuously rather than in a release sweep, and the README says the fuzzing tests are within the test/fuzz directory of the repository.

The second is a retraction, and it is in the go.mod rather than in the README. The go.mod declares retract v1.10.1 with the comment License issue.

That is worth pausing on, because a retraction in Go is not a soft signal. The retract directive tells the module tooling that the version should not be selected, so a go get that resolves to v1.10.1 is nudged away from it. If you have that version in a lockfile, the fix is to move to a later release, and 1.10.10 was published on 2026-09-10, so there is a straightforward upgrade path.

The Go version requirement is worth noting too. The go.mod says go 1.27, which is a recent floor, and the module also pulls in golang.org/x/crypto at 0.55.0 and x/oauth2 at 0.37.0, both current. This is a library that moves with the toolchain rather than lagging it.

The rest of the repository is the governance furniture you would expect from a project in this position: a CODEOWNERS file, a CODE_OF_CONDUCT.md, a POLICY.md, a RELEASING.md, a COPYRIGHT.txt alongside the LICENSE, a codecov.yml, and a .golangci.yml. The COPYRIGHT.txt is there because the project needs to track provenance across many contributors, and the README says that for example code, you should look at the relevant test code for each main code file, which is a real culture signal about how this project expects to be read.

## Where this sits against the tools built on it

The practical question for most people is whether to use this library or one of the tools built on it, and the README answers that directly for the most common case. For container signing, you want cosign.

So the division of labour is: cosign is the tool you run, and this library is the code it runs on. The same applies to Gitsign for signing Git commits, and to the infrastructure side, where Fulcio issues certificates and Rekor is the transparency log. Both of those are services, and they use the same shared code that you would use.

That sharing is the point of the repository. Signing with Fulcio requires an OpenID Connect flow, a key management client, a TUF root for the trust anchors, and the in-toto or DSSE signing formats, and getting that right once and sharing it means cosign, Gitsign and any third party tool behave the same way against the same authority. A tool written by someone else, in Go, that needs to produce a Sigstore signature can depend on this and get the same behaviour without reimplementing the protocol details.

The alternative is to reimplement against the Fulcio and Rekor APIs directly, which is what the Go clients did before this library existed. The cost of that is drift: your key handling, your TUF refresh, your attestation formatting will differ from everyone else's in small ways, and small differences in signature verification are exactly the kind of thing that turns into a security incident.

For a reader trying to understand the code, the README's advice is to look at the relevant test code for each main code file, and that is the right starting point for a library whose interface is a set of small behaviours rather than one obvious entry point.

## Conclusion

Adopt the sigstore library if you are writing a Go tool that has to produce Sigstore signatures, talk to a Fulcio certificate authority, or reach a key in a cloud KMS, and you would rather share one implementation with the rest of the ecosystem. Do not adopt it for container signing specifically, because the README points you at cosign for that, and do not expect it to be a complete Sigstore client on its own, since it holds the shared pieces rather than the command line tooling. Before you upgrade, check the go.mod retractions, since version 1.10.1 is retracted for a licence issue, and read the KMS documentation for the provider you need, since some of them are separate modules built from the same tree.

## FAQ

### What is the sigstore Go library used for?

It contains the common Sigstore code shared by infrastructure such as Fulcio and Rekor and by Go clients such as Cosign and Gitsign. It currently provides a signing interface supporting ecdsa, ed25519, rsa and DSSE for in-toto, plus OpenID Connect Fulcio client code.

### Which key management systems does the sigstore library support?

AWS Key Management Service, Azure Key Vault, HashiCorp Vault, Google Cloud Platform Key Management Service, OpenBao, and OVHcloud KMS, which is listed as an external plugin. Each provider lives in its own directory under pkg/signature/kms and is built as a separate Go module.

### Why was sigstore version 1.10.1 retracted?

The go.mod declares a retract directive for v1.10.1 with the comment License issue, so the module tooling avoids selecting that version. The next releases are 1.10.10 from 2026-09-10, 1.11.0 from 2026-09-21 and 1.11.1 from 2026-10-14.

### Should I use the sigstore library or cosign for container signing?

The README says that for container signing you want cosign, which is the Go client built on this shared library. The library itself is the shared code underneath, useful if you are writing your own Go tooling that has to sign or talk to a Fulcio certificate authority.

## Sources

- [License: Apache-2.0](https://github.com/sigstore/sigstore/blob/main/LICENSE)
- [Project website](https://sigstore.dev)
- [README](https://github.com/sigstore/sigstore/blob/main/README.md)
- [Releases](https://github.com/sigstore/sigstore/releases)
- [sigstore/sigstore on GitHub](https://github.com/sigstore/sigstore)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sigstore-sigstore