From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Eric Wong <normalperson@yhbt.net>,
Karsten Blees <karsten.blees@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 2/2] config: clear the executable bits (if any) on $GIT_DIR/config
Date: Mon, 17 Nov 2014 09:26:28 +0100 [thread overview]
Message-ID: <5469B134.1050306@alum.mit.edu> (raw)
In-Reply-To: <xmqqvbmfyo8w.fsf@gitster.dls.corp.google.com>
On 11/16/2014 07:49 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> There is no reason for $GIT_DIR/config to be executable, plus this
>> change will help clean up repositories affected by the bug that was
>> fixed by the previous commit.
>
> I do not think we want to do this.
>
> It is a welcome bugfix to create $GIT_DIR/config without executable
> bit when and only when we create it. It is very much in line with
> "There is no reason for $GIT_DIR/config to be executable"---we do
> not need to make it executable ourselves, so we shouldn't, but we
> did which was a bug we want to fix in patch 1/2 you posted.
>
> But with the "preserve existing permissions" fix we did earlier, the
> end users are now allowed to flip the executable bit on for their
> own purpose, and dropping it without knowing why they are doing so
> is simply rude. And honestly, Git do *not* even want to know why
> the users want to flip the bit.
>
> So I would suggest not to spend any cycle or any code complexity to
> "repair" existing repositories. Having that bit on does not hurt
> anybody. Those who found it curious can flip that bit off and then
> Git with "preserve existing permissions" fix will keep that bit off
> from then on.
I disagree. The point of "preserve existing permissions" was to allow
people to make their config files more readable/writable than the
default, with the main use case being to help users who want to hide
secret information in their config files.
I think it is really far-fetched to imagine that anybody made his config
file executable on purpose. Whereas we are *sure* that we have created
lots of repositories with config files that were set executable by accident.
Let's redefine the "feature" that was added in 2.1 from "preserve
existing permissions" to "preserve existing read/write permissions" and
thereby help people clean up the mess we made.
That being said, I still believe that executable config files are not a
significant risk in practice, so I'm not going to lose sleep about it
either way.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
next prev parent reply other threads:[~2014-11-17 8:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-15 7:26 [PATCH 0/2] Don't make $GIT_DIR executable Michael Haggerty
2014-11-15 7:26 ` [PATCH 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config Michael Haggerty
2014-11-15 12:06 ` Torsten Bögershausen
2014-11-16 5:23 ` Michael Haggerty
2014-11-15 7:26 ` [PATCH 2/2] config: clear the executable bits (if any) " Michael Haggerty
2014-11-15 7:32 ` Stefan Beller
2014-11-15 7:42 ` Michael Haggerty
2014-11-16 18:49 ` Junio C Hamano
2014-11-17 8:26 ` Michael Haggerty [this message]
2014-11-17 15:33 ` Junio C Hamano
2014-11-17 16:00 ` Michael Haggerty
2014-11-15 7:50 ` [PATCH 0/2] Don't make $GIT_DIR executable Eric Wong
2014-11-16 6:14 ` Michael Haggerty
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5469B134.1050306@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karsten.blees@gmail.com \
--cc=normalperson@yhbt.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.
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 NNTP newsgroup(s).