git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Julian Brost <julian@0x4a42.net>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: Trust issues with hooks and config files
Date: Mon, 10 Mar 2014 08:18:26 -0700	[thread overview]
Message-ID: <xmqqiormrsjh.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <531CA468.3060604@0x4a42.net> (Julian Brost's message of "Sun, 09 Mar 2014 18:27:04 +0100")

Julian Brost <julian@0x4a42.net> writes:

> On 07.03.2014 22:04, Jeff King wrote:
>> 
>> If you want to work on it, I think it's an interesting area. But
>> any development would need to think about the transition plan for
>> existing sites that will be broken.
>
> I can understand the problem with backward compatibility but in my
> opinion the default behavior should definitely be to ignore untrusted
> config files and hooks as it would otherwise only protect users that
> are already aware of the issue anyways and manually enable this option.
>
> Are there any plans for some major release in the future that would
> allow introducing backward incompatible changes?

Git 2.0 has been in the planning for quite some months, and I am
inclined to merge these topics prepared for that release to 'master'
during this cycle.  Anything new like this one is way too late for
it, but that does not mean we can never do 3.0 in the future.

Perhaps going this way might be possible:

 * Introduce a configuration that is read only from $HOME/.gitconfig
   (or its xdg equivalent) to enable or disable the "unsafe" behaviour.

   By default (i.e. when the above configuration is not set), allow
   "unsafe" read; when instructed by the above configuration to
   forbid "unsafe" read, ignore configuration files that are not
   owned by the owner of the process.  People can toggle the
   "unsafe" read to experiment with the above (~gitdaemon/.gitconfig
   can perhaps be used to restrict the daemon access)

   Keep it that way for a few releases.

 * After a few releases, start warning people who do not have the
   "unsafe" option in their $HOME/.gitconfig about a future default
   change, to force them to explicitly set it.

   Keep it that way for a few releases.

 * Flip the default, perhaps still keeping the warning on the
   flipped default to help people who have not been following along.

   Keep it that way for a few releases.

 * Then finally remove the warning.

A release cycle usually last 10-12 weeks on average.

  reply	other threads:[~2014-03-10 15:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06 21:47 Trust issues with hooks and config files Julian Brost
2014-03-07 21:04 ` Jeff King
2014-03-09 17:27   ` Julian Brost
2014-03-10 15:18     ` Junio C Hamano [this message]
2014-03-16 13:45     ` Sitaram Chamarty

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=xmqqiormrsjh.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=julian@0x4a42.net \
    --cc=peff@peff.net \
    /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).