| commit | 605edab4323bfdf06a0d8ac68b4b18e9e0df249b | [log] [tgz] |
|---|---|---|
| author | Filippo Valsorda <hi@filippo.io> | Wed Nov 17 16:38:00 2021 -0500 |
| committer | Gopher Robot <gobot@golang.org> | Wed Mar 30 20:53:32 2022 +0000 |
| tree | 43e491fb69ea477b470cf0e1b6b70431cdac6b80 | |
| parent | a410e2daa716f879ede62862a0351cad3606d11b [diff] |
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 Reviewed-on: https://go-review.googlesource.com/c/mod/+/364856 Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Trust: Filippo Valsorda <filippo@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
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.