1
0
mirror of synced 2026-10-24 12:59:22 +03:00
Files
Pujitha Paladugu ff2a8f4ea2 fix(sign): pass digest hash algorithm to underlying signer in SignData
Fixes #5018

Motivation

Signing with a HashiCorp Vault Transit KMS ECDSA P-521 key fails with
"signing digest: signing bundle: error signing bundle: unexpected
length of digest for hash function specified". This is a regression
in the bundle-signing path introduced when SignerVerifierKeypair was
added: it correctly computes the digest using the key's own default
hash algorithm (SHA-512 for P-521), but never told the underlying
signer.SignMessage which hash algorithm that digest was produced with.

KMS-backed SignerVerifiers created via
pkg/signature/keys.go:SignerVerifierFromKeyRef are constructed with a
hardcoded crypto.SHA256 default (unrelated to the actual key's curve),
so sigstore-go's ComputeDigestForSigning fell back to that default,
saw a 64-byte digest against an expected 32-byte SHA-256 digest, and
rejected it with the mismatch error above.

Approach

internal/key/svkeypair.go: SignerVerifierKeypair.SignData now also
passes signatureoptions.WithCryptoSignerOpts(hashType) alongside
WithDigest(digest), so the signer is told exactly which hash algorithm
produced the digest, regardless of what hash it was constructed with
by default. This affects every SignerVerifier-backed signing path (any
KMS provider, not just Vault) whenever the key's natural hash isn't
SHA-256 (e.g. P-384/P-521 ECDSA, larger RSA keys). For keys whose
natural hash is already SHA-256 (e.g. default P-256), this is a no-op:
the newly-passed option matches the signer's existing default.

Validation

go build ./...
go test ./internal/key/... ./pkg/signature/... ./pkg/cosign/bundle/... -count=1
  ok  	github.com/sigstore/cosign/v3/internal/key
  ok  	github.com/sigstore/cosign/v3/pkg/signature
  ok  	github.com/sigstore/cosign/v3/pkg/cosign/bundle

Added TestKMSKeypair_ECDSA_P521_SignData, which reproduces the digest
length/hash mismatch reported in the issue (verified it fails without
this fix with "expected underlying signer to be given crypto.SHA512
opts matching the digest, got <nil>", and passes with it). This was
verified with a unit test against a mock SignerVerifier reproducing
the KMS signer's option-handling behavior; it was not validated
against a live HashiCorp Vault instance.

Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
2026-10-01 11:05:45 -07:00
..