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.
next prev parent 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).