Re: git signed push server-side
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 26, 2017, 01:01 UTC
- Message-ID
- <xmqqshgfqh0g.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170826003229.GL13924@aiede.mtv.corp.google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 22 quoted lines
> +Dave Borowitz, who implemented push cert handling in JGit and Gerrit > Hi Ian, > > Ian Jackson wrote[1]: > >> I have been investigating git signed pushes. I found a number of >> infelicities in the server side implementation which make using this >> in practice rather difficult. I'm emailing here (before writing >> patches) to see what people think of my proposed changes. >> >> 1. PUSH_CERT_KEY has truncated keyid (Debian #852647) >> >> I see this: >> GIT_PUSH_CERT_KEY=A3DBCBC039B13D8A >> >> There is almost no purpose for which this 64-bit keyid can be safely >> used. The full key fingerprint should be provided instead. >> >> Proposed change: provide the full fingerprint instead. Do this >> for every caller of gpg-interface.c. > > Sounds sane.
I probably should react a bit stronger against that "instead", as Ian will not be writing the world's first server side hook that uses this interface. A different variable that lets you read the full length "in addition" I wouldn't have a problem with, as existing scripts will continue working the same way if you did so.
But on the other hand, the value of this environment is not meant to be used to make decision by the hook anyway, so it perhaps is OK to change it in a backward incompatible way to break those who have been using the value for any serious purpose.
The purpose of the signed push is not to replace authentication and authorization. The primary goal behind the signed push mechanism is to allow server side hook to implement a way to store these certs in the order it receives without losing them, and that gives a way for the server operators to protect against claims that they are showing what the pusher did not intend to publish. They can say "the tip of these branches are at this commit, because, see this, a signed cert by the pusher asking us to put these commits at these branches" with such a mechanism---as opposed to "we authenticated the user and here is our server log that says that user pushed to update these refs", which is much weaker claim that they can make without the signed push mechanism.