Re: Push Certificates: Privacy Concerns Regarding the "pushee" Header

So, imagine a world where push certificates are more "end-to-end". Think transparency log meets Git (see https://transparency.dev/ for more context). Not only `git push --signed`, but also `git pull --signed` exists. The remote being fetched from must provide evidence for the puller verify the range being pulled, e.g. 0000000..ccae4e0. It does so by sending along the blob that contains the corresponding push certificates[^1].

In this bright future, where any puller is an auditor, you would run into an issue if you want your repository to be pulled from different places (pullees? fetchees?). However, there is a way out: Let the pusher specify with which locations they are happy to have their push end up at. In your case, since you are happy for others to pull from https://github.com/gitster/git, you add to your push certificate:

	certificate version 0.1
	pusher SHA256:xX6bp…T0  1771188983 +0100
	pushee https://example.com/repo.git
	pushee git@github.com:gitster/git.git
	nonce 1771188983-345389c

	0000000 ccae4e0 refs/heads/main

I will also give you the counter arguments: Firstly, with repositories that have many mirrors, the number of headers might become problematically large. One remedy would be to allow configuration of aliases on the side of the puller/verifier. One could accept all values of `remote.<name>.url` as valid. One could introduce `remote.<name>.alias`. Secondly, for repositories with exactly one canonical location, no configuration would be necessary and the value being used today would be correct.

---

[1]: In general, it would have to send multiple push certificates. Firstly because there might be multiple refs being pulled over multiple ranges. Secondly because that range might have been established over multiple pushes.