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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 17, 2026, 19:42 UTC
Message-ID: <xmqqldgrb1ha.fsf@gitster.g>
In-Reply-To: <d180884c-8108-4c8a-9cc7-5314a4f5a45a@posteo.eu>

Lorenz Leutgeb <lorenz.leutgeb@posteo.eu> writes:

Show 14 quoted lines

> This would result in push certificates of the following form (hashes 
> abbreviated, signature omitted):
>
> 	certificate version 0.1
> 	pusher SHA256:xX6bp…T0  1771188983 +0100
> 	pushee /home/lorenz/.example/storage/foo
> 	nonce 1771188983-345389c
> 	
> 	0000000 ccae4e0 refs/heads/main
>
> As you can see, this push certificate leaks a path on the application 
> users' filesystem.  Here it is quite obviously my home directory, but 
> actually the "storage path", is user-configurable at the application 
> level, and considered private.

Stepping back a bit, the most important question is what the signer is trying to certify, isn't it?

"At this point in time, I am pushing to update these refs because I want these objects to be sitting at the tip of them in the repository listed as pushee" is the statement the pusher is certifying. The auditors can point at the certificate that the hosting site having the object ccae4e0 is not because insiders of the hosting site rewounded the tip to point at a stale object that the pusher did not want to see at the ref, but with that signature, this pusher expressed their desire to have it at the tip of the main branch.

Making it possible to lift that certification and reusing it for a push to different repository smells like opening a door for replay attacks, doesn't it? The pusher did not say anything about updating these refs in other repositories that are different from the pushee repository.

I am not sure what the implication of optionally allowing the pusher to sign a certificate that lacks "pushee" is. Would that be a reasonable way to say "at this point in time, I want this object to be at the tip of main branch in _any_ and _all_ clones of this project anywhere in the world?" Is that the kind of statement the pusher would want to make in the first place? Would such a statement even make sense? When you are dealing with two related repositories of a project (e.g., one may be the main development repository, the other being the repository for the maintenance track), I may fully stand behind putting this commit at the tip of 'main' on the development track, but that no way means I would be OK to put the same commit at the tip of 'main' on the maintenance track. Not naming "pushee" does not sound like it would fly well.

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? You give the history together with a signed "I want the object ccae4e0 at the tip of the main branch" statement to your middleman, and your middleman does the actual update and forwards your certificate. 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.