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

You point out that a push certificate without a pushee is questionable (to say the least) and opens the door to replay attacks. I understand and agree. Thank you.

So let me cross out the option `--no-signed-pushee` and empty values for `--signed-pushee=<url>` from my previous proposal, and let us continue our discussion under the assumption that the pushee header is always set to a URL(-like) string.

On 2026-02-17 11:42-0800, Junio C Hamano wrote:
 > What implication does it have to allow the pusher to sign a
 > certificate that points at a "pushee" that is different from the
 > repository the signer directly pushed into?  [...]  I offhand do not
 > see a huge security problem in that arrangement.  Anybody can check
 > the certificate and the resulting history and verify the chain of
 > hashes to the same degree as you would trust SHA-1 (or SHA-256) for
 > the object integrity and GPG (or whatever you used to sign the push
 > certificate) for the certificate integrity.

Exactly. And this is very much the situation I am in. The middleman is actually the daemon that comes bundled with the application, which wants share the push certificate over the network. The pusher only has to trust the middleman insofar as the middleman will actually forward the push to its best ability. In my application, distribution of the certificates and syncing of objects is the main purpose of the daemon. But I digress...

Let me zoom in a bit more why I want to override the pushee: The way the application works is by means of a remote helper. That is, the user executes `git push example://foo ccae4e0:main`. This is makes sense in the context of the application, as the user wants to carry out a logical "push to the network", and "foo" is an identifier that also has a well-defined meaning within the context of the application. As you know, this will lead to execution of `git-remote-example`. The remote helper is where the hand-off between "plain Git" and the application happens. The remote helper knows that the push will be split in two parts. It knows that it must carry out the first part immediately, which is a push to `home/lorenz.example/storage/foo`. The repository at that path is the local view of the repository `example://foo` on the users filesystem. This local repository then gets updated in the background by the daemon, and the daemon also notifies other peers on the network about the push. This is the part where it must act as the middleman.

Now, in the context of the application, the global identifier of the repository across the network, and thus the pushee that I would like to see, is `example://foo`. The path `home/lorenz.example/storage/foo` is merely a local name for it, like a cached copy if you will.

Perhaps this even raises a question on how remote helpers interact with signed pushes: If Git allows to register URLs via remote helpers, how should remote helpers that do not have the "connect" capability control the pushee URL, which they likely are concerned with?