It was a mistake to assume a fixed algorithm in the repository format and client-server protocol. I remember being surprised when I learned about that choice, being familiar with cryptographic protocols and formats where the hash algorithm is usually a parameter that can vary for each concrete hash.

▲

loeg 3 hours ago | parent | next [-]

> being familiar with cryptographic protocols and formats where the hash algorithm is usually a parameter that can vary for each concrete hash.

This flexibility ("agility") in cryptographic protocols is often seen as a mistake today, actually.

	▲	WorldMaker an hour ago \| parent [-]
		Cryptographic protocols have been moving towards something of a compromise in flexibility. "Everything flexible" is a security risk, especially when "everything" includes "fallback to nothing secure". "No flexibility" is a security risk because you can't upgrade. The middle path is something like "version numbers" with hard breakpoints. "I only support v2 of this cryptographic protocol and will not fallback to v1." Which is sort of the hash algorithm approach git is taking with incompatible versions and a version break.

▲

throw0101c 6 hours ago | parent | prev | next [-]

> It was a mistake to assume a fixed algorithm in the repository format and client-server protocol.

See also perhaps Wireguard, which touts itself as not having "cryptographic agility" because they wanted to avoid all (perceived) problems and complications of IPsec. But now that PQC is (allegedly) approaching there's no easy to update things because (AIUI) there's no negotiation possible in the protocol; you're basically standing up a 'Wireguard 2.0' that runs separately than the original.

	▲	akerl_ 2 hours ago \| parent [-]
		That is in fact the idea, and was on purpose.

▲

throwawayffffas 41 minutes ago | parent | prev [-]

1. As others have noted, flexibility in cryptographic protocols is generally a mistake.

2. The hash function is not used for cryptographic purposes!