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:16:51 -0700	[thread overview]
Message-ID: <xmqqo9r3qgak.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:

> I think respecting gpg.program would be nicer.  Is there a reason not
> to do that?
>
> I suspect receive-pack just forgot to call git_gpg_config.

That would be a good change.

> How is the keyring configured for other commands that use GPG, like
> "git tag -v"?  (Forgive my laziness in not looking it up.)

AFAIR we never do anything special, so you should be able to point
GNUPGHOME to wherever you like to use the desired configuration.

> I also wonder why you say the git configuration system is unsuited to
> keeping secrets.  E.g. passing an include.path setting with -c or
> GIT_CONFIG_PARAMETERS should avoid the kinds of trouble you described.
> Is there a change we could make to make it work better?  That said, I
> think being able to name a file is a good idea.

I also wonder that too.  The configuration file that has the
filename could be made just as secret and unreadable from public as
the new file that stores the seed with the same mechanism, I would
imagine.

>> 5. There are no docs on how to use this feature properly
>>    (Debian #852695, #852688 part 1)
>>
>> Using the signed push feature requires careful programming on the
>> server side.  There should be a doc explaining how to do this.

This was rather deliberately left underspecified, hoping that the
BCP would emerge after people gain experience.  As Ian is looking
into this and hopefully gain real-world experience, we can have a
good BCP description after he is done with his project ;-)

> Yes, that sounds like a very welcome kind of thing to add.

Indeed.

      parent reply	other threads:[~2017-08-26  1:16 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
2017-08-26  9:12     ` git signed push server-side [and 3 more messages] Ian Jackson
2017-08-26  1:16   ` Junio C Hamano [this message]

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=xmqqo9r3qgak.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).