GHSA-3633-5h82-39pq Go-tuf Improperly handles multiple key IDs for the same public keys in attacker-controlled metadata

• Go github.com/theupdateframework/go-tuf: < 0.3.2 → fixed in 0.3.2

Issue If an attacker is able to control a threshold of keys to insert the same public key more than once with different key IDs into signed, trusted metadata on a TUF repository, then go-tuf clients = 0.3.2. Workarounds Users can work around this vulnerability in previous clients by checking for and removing _duplicate_ public keys with different key IDs (e.g., SHA2-256 and SHA2-512 hashes of the same public key) in all signed metadata on their TUF repositories. References • The PR fixing this issue is #369. • The latest TUF specification advises using only SHA2-256 hashes of public keys. • Commit b383bafd27472310a650f3733e686163a868b71a removed support for clients generating multiple key IDs for the same public key. This commit is older than the first v.0.1.0 tag for go-tuf. • There is an outstanding issue for removing the non-standard `keyid_hash_algorithms` field in TUF metadata which arguably led to this issue. • A more robust solution is discussed (but not necessarily recommended) in TAP 12, which suggests deduplicating public keys even more strongly on the basis of the fundamental parameters (e.g., exponents) to the cryptosystem rather than specific encodings (e.g., PEM) of public keys. For more information If you have any questions or comments about this advisory: • Open an issue in go-tuf • Email us at TUF's mailing list • The #tuf channel on CNCF Slack.