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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.