Donating `model-transparency-go`

[sampras343]

Description
I would like to donate model-transparency-go -- a Go implementation of the model-signing library that provides ML model integrity and provenance verification using the Sigstore ecosystem. The project supports signing and verifying ML models via Sigstore (keyless), private keys, X.509 certificates, and PKCS#11/HSMs, produces Sigstore bundle format v0.3, and maintains full bidirectional interoperability with the Python model-signing package (tested in CI against model-signing v1.1.1).

I presented this project at the OpenSSF Model Signing SIG Meeting on 11th February 2026 and received positive interest from maintainers and community members.

Motivation:

• Community Need: There was an open request in the sigstore/model-transparency (issue #414) for a Go implementation to enable direct, synchronous model signing from Go applications and also enable direct integration with cloud-native applications without depending on Python FFI or subprocess wrappers.
• Ecosystem Alignment: Almost every core Sigstore component is written in Go, so a Go model-signing library keeps it ecosystem native.
• Model Validation Operator: The MVO currently shells out to the Python CLI for continuous model verification; a Go library helps native integration and eliminates Py runtime deps. PR Link
• Personal Growth: I am fairly new to the Sigstore community and saw this as the ideal entry point.

Features:

• Hashing: SHA256 (default) and Blake2
• Serializations: File and Shard
• Signing and Verifying:
  • Default Sigstore Flow
  • Public-Private Key
  • Certificate
  • OCI Manifest
  • Compatibility with Python package (0.0.1 to 1.1.1)
• Open Telemetry Integration
  • Open Telemetry tracing is an opt-in via the otel tag.
  • Sign and Verify operation attributes are exported via OLTP to any compatible backend (Grafana, Jaeger)
• Interfaces
  • CLI Interface
  • High Level Go Library
  • Low Level Go library

High Level Architecture:

Current Repository Link: https://github.com/sigstore/model-transparency
Documentation: https://github.com/sampras343/model-transparency-go/blob/main/README.md

Next Steps:

• PCKS#11 Integration
• KMS Integration
• ORAS Integration
• Migration to claims.jsonl after finalization
• Model Lineage

[sampras343]

Additional Information:

CLI Interface:

sign Subcommands

• sign sigstore (default)

Keyless signing via Sigstore (Fulcio CA + Rekor transparency log).

Flag	Description
--use-staging	Use Sigstore's staging environment
--trust-config	Path to custom trust configuration JSON
--oauth-force-oob	Force out-of-band OAuth flow (no browser)
--use-ambient-credentials	Use credentials from ambient environment (CI/CD)
--identity-token	Fixed OIDC identity token (skips OIDC flow)
--client-id	Custom OpenID Connect client ID
--client-secret	Custom OpenID Connect client secret

• sign key

Sign using a local private key.

Flag	Description
--private-key	Path to PEM-encoded private key
--password	Password for encrypted private key

• sign certificate

Sign using an X.509 certificate and private key.

Flag	Description
--private-key	Path to PEM-encoded private key
--signing-certificate	Path to PEM-encoded signing certificate
--certificate-chain	Intermediate certificate chain files

• sign pkcs11-key [WIP]

Sign using a PKCS#11 hardware security module (key-based).

Flag	Description
--pkcs11-uri	RFC 7512 PKCS#11 URI (token, key, module, PIN)
--module-paths	Additional PKCS#11 module search directories

• sign pkcs11-certificate [WIP]

Sign using a PKCS#11 hardware security module with certificate.

Flag	Description
--pkcs11-uri	RFC 7512 PKCS#11 URI (token, key, module, PIN)
--signing-certificate	Path to PEM-encoded signing certificate
--certificate-chain	Intermediate certificate chain files
--module-paths	Additional PKCS#11 module search directories

verify Subcommands

Shared Verify Flags:

These flags are available on all verify subcommands.

Flag	Description
--signature	Output signature file to verify (required)
--ignore-paths	File paths to exclude from verification
--ignore-git-paths	Automatically exclude git-related files
--allow-symlinks	Follow symbolic links when hashing
--ignore-unsigned-files	Ignore files in model not present in signature

• verify sigstore (default)

Verify a Sigstore-signed model against identity and OIDC provider.

Flag	Description
--identity	Expected signer identity (e.g., name@example.com)
--identity-provider	Expected OIDC issuer URL (e.g., https://accounts.google.com)
--use-staging	Use Sigstore's staging environment
--trust-config	Path to custom trust configuration JSON

• verify key

Verify a model signed with a private key.

Flag	Description
--public-key	Path to PEM-encoded public key

• verify certificate

Verify a model signed with an X.509 certificate.

Flag	Description
--certificate-chain	CA and intermediate certificate chain files
--log-fingerprints	Log SHA256 fingerprints of all certificates

Global Options

Available on all commands (sign, verify, version).

Flag	Default	Description
--log-level	info	Minimum log level (debug, info, warn, error, silent)
--log-format	text	Log output format (text, json)
--output-file	stdout	Redirect log output to a file
--timeout, -t	3m	Command execution timeout

[Hayden-IO]

I'm not on the TSC, but I've got few questions.

What's the use case for this reimplementation? I see the issue mentioned cloud-native tooling, but is there anything more concrete? Who's going to be using this implementation?

Why did you choose to reimplement a CLI in addition to the library? Having two potentially divergent CLIs for model signing under the same org isn't ideal.

Had you considered implementing only the canonicalization of a model into a hash, to be signed by sigstore-go? This is more in line with how we've talked about Sigstore tooling that's built on top of the SDKs - Cosign canonicalizes containers, Gitsign canonicalizes git commits, etc. A library that's much smaller and focused exclusively on providing a Go API for canonicalization of a model would be easier to maintain as well.

I see that Mihai mentioned that they were working towards a specification but nothing had been finalized yet. Without a spec and a way to track conformance between the two libraries, I think it's premature to have a second implementation. My suggestions would be a) work with the model signing community to finalize a specification around signing and verification, b) have a more minimal library without a CLI, c) demonstrate usage of this library, or at least planned usage, with other tooling.

[david-a-wheeler]

Awesome!

I have a technical comment that I also made in sigstore/model-transparency#587 that I hope you would find helpful.

I would strongly urge considering creating new subdirectories for signatures from multiple orgs, instead of having organizations try to co-edit the same file. That way, instead of trying to "merge" modifications to the same file from different organizations, you simply accept subdirectories. This was a lesson learned from the Linux system package distributors, who eventually created many subdirectories (*.d) to make it easy to add and maintain things.