Secret Manager validation fails when using `versions/latest`

[celia-vytrac]

Description

The secret() function in cmd/tesseract/gcp/secret_manager.go incorrectly validates Secret Manager responses when using versions/latest.

What I Observed

When requesting a secret using versions/latest (e.g., projects/123/secrets/my-secret/versions/latest), the Secret Manager API returns the resolved version path in resp.Name (e.g., projects/123/secrets/my-secret/versions/4).

The comparison fails because these strings don't match:

if resp.Name != secretName {
    return nil, errors.New("request corrupted in-transit")
}

This causes a misleading "request corrupted in-transit" error even though the request completed successfully.

How to reproduce

1. Deploy tesseract GCP binary with signer keys using versions/latest:

   --signer_public_key_secret_name=projects/{project}/secrets/{secret}/versions/latest
   

Environment

• tesseract version: v0.1.1
• Image: ghcr.io/transparency-dev/tesseract/gcp:v0.1.1

Expected behavior

Ideally, if this is intended behavior and latest is deliberately not supported, a different error should report that to the user.

If latest support is desirable:

1. Remove the name comparison (the CRC32C checksum validation already ensures data integrity)
2. Normalize the comparison by accepting latest

Workaround

Use explicit version numbers instead of latest. (Which requires manual updates when rotating secrets)

The flag documentation says Format: projects/{projectId}/secrets/{secretName}/versions/{secretVersion} which implies latest is valid, but the terragrunt examples all use explicit version numbers like versions/1.

[phbnf]

Over to @AlCutter who's worked on this recently.

[AlCutter]

On the face of it, I'm not sure if it makes sense to use anything other than a numbered version when specifying the log key; CT today has no support for rotating the key of logs, rather, since logs now all have a short defined lifetime (usually 6 months), we just see entire logs rotate in and out.

Even if the CT ecosystem were to support key rotation, there would have to be a period of time after the key is created for the public key to be rolled out to all the log clients or we'd risk breakage. To avoid such breakage, any operator would need to be intentional about when it switched to using the new key. However, using latest in the resource identifier would, I suspect, result in switching over to the new key at the point at which individual tesseract tasks are restarted, which is probably not what would be wanted (e.g. if multiple instances are running concurrently, this could even result in each instance using a different version of the key to sign SCTs and checkpoints).

Of course, if you're using tesseract in a different non-webPKI context this all may not be relevant to you, in which case we'd love to hear more about your use-case @celia-vytrac !