git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>,
	git@vger.kernel.org, Dave Borowitz <dborowitz@google.com>
Subject: Re: git signed push server-side
Date: Fri, 25 Aug 2017 18:01:19 -0700	[thread overview]
Message-ID: <xmqqshgfqh0g.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170826003229.GL13924@aiede.mtv.corp.google.com> (Jonathan Nieder's message of "Fri, 25 Aug 2017 17:32:29 -0700")

Jonathan Nieder <jrnieder@gmail.com> writes:

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

  reply	other threads:[~2017-08-26  1:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-25 21:24 git signed push server-side Ian Jackson
2017-08-25 22:11 ` Junio C Hamano
2017-08-26  0:32 ` Jonathan Nieder
2017-08-26  1:01   ` Junio C Hamano [this message]
2017-08-26  9:12     ` git signed push server-side [and 3 more messages] Ian Jackson
2017-08-26  1:16   ` git signed push server-side Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqshgfqh0g.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=dborowitz@google.com \
    --cc=git@vger.kernel.org \
    --cc=ijackson@chiark.greenend.org.uk \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).