sumdb/note: relax prescriptiveness of key hash format

The key hash is too short to serve a cryptographic purpose: it is
trivial for example to generate two names that given the same private
key end up with the same key hash. That means the only thing the key
hash does is help pull up the right Verifier, similarly to the X.509
Subject Key ID/Authority Key ID. That's ok.

It's also the case that the Open and Verifier APIs don't enforce a key
hash scheme, so each Signer/Verifier implementation is free to implement
its own. There is already in the ecosystem an ECDSA based implementation
that uses the hash of the SPKI for the key hash (which notably does not
include the name).

We could either try to enforce that every implementation use an
equivalent or specified key hash algorithm, or relax the prescriptiveness.
I think that the latter is the right choice given that as mentioned
above we don't need (or can get) extra properties out of it.

Change-Id: I9730cef862604aa8608d68f7f204f5dddfb4a39b
Run-TryBot: Filippo Valsorda <>
Auto-Submit: Filippo Valsorda <>
Trust: Filippo Valsorda <>
Reviewed-by: Russ Cox <>
TryBot-Result: Gopher Robot <>
1 file changed
tree: 43e491fb69ea477b470cf0e1b6b70431cdac6b80
  1. gosumcheck/
  2. internal/
  3. modfile/
  4. module/
  5. semver/
  6. sumdb/
  7. zip/
  8. codereview.cfg
  9. go.mod
  10. go.sum



This repository holds packages for writing tools that work directly with Go module mechanics. That is, it is for direct manipulation of Go modules themselves.

It is NOT about supporting general development tools that need to do things like load packages in module mode. That use case, where modules are incidental rather than the focus, should remain in x/tools, specifically x/tools/go/packages.

The specific case of loading packages should still be done by invoking the go command, which remains the single point of truth for package loading algorithms.