RFC: "git config -l" should not expose sensitive information

RFC: "git config -l" should not expose sensitive information

[Toralf Förster]

often the output is requested in help forums - and a
"git config -l | wgetpaste" exposes parameters like sendmail.smtppass -
so hide those variables in the output (if not explicitly wanted) would
makes sense, or ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: RFC: "git config -l" should not expose sensitive information

[Jeff King]

On Mon, Dec 17, 2012 at 12:35:54PM +0100, Toralf Förster wrote:

> often the output is requested in help forums - and a
> "git config -l | wgetpaste" exposes parameters like sendmail.smtppass -
> so hide those variables in the output (if not explicitly wanted) would
> makes sense, or ?

But if we change "git config -l", won't that break all of the
non-exposing uses that rely on seeing all of the variables (e.g., it is
perfectly fine for a porcelain to parse "git config -l" rather than
making several calls to "git config"; IIRC, git-cola does this).

The problem seems to be that people are giving bad advice to tell people
to post "git config -l" output without looking at. Maybe we could help
them with a "git config --share-config" option that dumps all config,
but sanitizes the output. It would need to have a list of sensitive keys
(which does not exist yet), and would need to not just mark up things
like smtppass, but would also need to pull credential information out of
remote.*.url strings. And maybe more (I haven't thought too long on it).

-Peff

Re: RFC: "git config -l" should not expose sensitive information

[Aaron Schrab]

At 10:04 -0500 20 Dec 2012, Jeff King <peff@peff.net> wrote:
>The problem seems to be that people are giving bad advice to tell 
>people to post "git config -l" output without looking at. Maybe we 
>could help them with a "git config --share-config" option that dumps 
>all config, but sanitizes the output. It would need to have a list of 
>sensitive keys (which does not exist yet), and would need to not just 
>mark up things like smtppass, but would also need to pull credential 
>information out of remote.*.url strings. And maybe more (I haven't 
>thought too long on it).

If such an option is added, it is likely to cause more people to think 
that there is no need to examine the output before sharing it.  But, I 
don't think that the sanitizing could ever be sufficient to guarantee 
that.

Tools outside of the core git tree may add support for new config keys 
which are meant to contain sensitive information, and there would be no 
way for `git config` to know about those.

Even for known sensitive keys, the person entering it might have made a 
typo in the name (e.g.  smptpass) preventing it from being recognized as 
sensitive by the software, but easily recognizable as such by a human.

There's also the problem of varying opinions on what is considered as 
sensitive.  You mention credential information in URLs, but some people 
may consider the entire URL as something which they would not want to 
expose.

I think that attempting to do this would only result in a false sense of 
security.

Re: RFC: "git config -l" should not expose sensitive information

[Michael Haggerty]

On 12/20/2012 04:04 PM, Jeff King wrote:
> On Mon, Dec 17, 2012 at 12:35:54PM +0100, Toralf Förster wrote:
>> often the output is requested in help forums - and a
>> "git config -l | wgetpaste" exposes parameters like sendmail.smtppass -
>> so hide those variables in the output (if not explicitly wanted) would
>> makes sense, or ?
> 
> But if we change "git config -l", won't that break all of the
> non-exposing uses that rely on seeing all of the variables (e.g., it is
> perfectly fine for a porcelain to parse "git config -l" rather than
> making several calls to "git config"; IIRC, git-cola does this).
> 
> The problem seems to be that people are giving bad advice to tell people
> to post "git config -l" output without looking at. Maybe we could help
> them with a "git config --share-config" option that dumps all config,
> but sanitizes the output. It would need to have a list of sensitive keys
> (which does not exist yet), and would need to not just mark up things
> like smtppass, but would also need to pull credential information out of
> remote.*.url strings. And maybe more (I haven't thought too long on it).

I think the problem is yet another step earlier: why do we build tools
that encourage people to store passwords in plaintext in a configuration
file that is by default world-readable?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: RFC: "git config -l" should not expose sensitive information

[Jeff King]

On Thu, Dec 20, 2012 at 10:49:15AM -0500, Aaron Schrab wrote:

> At 10:04 -0500 20 Dec 2012, Jeff King <peff@peff.net> wrote:
> >The problem seems to be that people are giving bad advice to tell
> >people to post "git config -l" output without looking at. Maybe we
> >could help them with a "git config --share-config" option that
> >dumps all config, but sanitizes the output. It would need to have a
> >list of sensitive keys (which does not exist yet), and would need
> >to not just mark up things like smtppass, but would also need to
> >pull credential information out of remote.*.url strings. And maybe
> >more (I haven't thought too long on it).
> 
> If such an option is added, it is likely to cause more people to
> think that there is no need to examine the output before sharing it.
> But, I don't think that the sanitizing could ever be sufficient to
> guarantee that.
> 
> Tools outside of the core git tree may add support for new config
> keys which are meant to contain sensitive information, and there
> would be no way for `git config` to know about those.

Good point. I was a little on the fence already because any time you
have a "prevent known bad" list in a security setting, it is guaranteed
to go out of date and screw you. But the presence of third-party tools
means it does not even have to get out of date. It will always be
complete.

> I think that attempting to do this would only result in a false sense
> of security.

Yeah. Thanks for a dose of sanity. I was really trying not to say "the
given advice is bad, and we cannot help those people". But I think you
are right; the only sensible path is for the user to inspect the output
before posting it.

-Peff

Re: RFC: "git config -l" should not expose sensitive information

[Jeff King]

On Thu, Dec 20, 2012 at 04:51:37PM +0100, Michael Haggerty wrote:

> > The problem seems to be that people are giving bad advice to tell people
> > to post "git config -l" output without looking at. Maybe we could help
> > them with a "git config --share-config" option that dumps all config,
> > but sanitizes the output. It would need to have a list of sensitive keys
> > (which does not exist yet), and would need to not just mark up things
> > like smtppass, but would also need to pull credential information out of
> > remote.*.url strings. And maybe more (I haven't thought too long on it).
> 
> I think the problem is yet another step earlier: why do we build tools
> that encourage people to store passwords in plaintext in a configuration
> file that is by default world-readable?

Agreed. Most of it is hysterical raisins. We did not have any portable
secure storage for a long time. These days we have the credential helper
subsystem, which send-email can and should be using.

-Peff

Re: RFC: "git config -l" should not expose sensitive information

[Toralf Förster]

yep - understood


On 12/20/2012 04:49 PM, Aaron Schrab wrote:
> At 10:04 -0500 20 Dec 2012, Jeff King <peff@peff.net> wrote:
>> The problem seems to be that people are giving bad advice to tell
>> people to post "git config -l" output without looking at. Maybe we
>> could help them with a "git config --share-config" option that dumps
>> all config, but sanitizes the output. It would need to have a list of
>> sensitive keys (which does not exist yet), and would need to not just
>> mark up things like smtppass, but would also need to pull credential
>> information out of remote.*.url strings. And maybe more (I haven't
>> thought too long on it).
> 
> If such an option is added, it is likely to cause more people to think
> that there is no need to examine the output before sharing it.  But, I
> don't think that the sanitizing could ever be sufficient to guarantee that.
> 
> Tools outside of the core git tree may add support for new config keys
> which are meant to contain sensitive information, and there would be no
> way for `git config` to know about those.
> 
> Even for known sensitive keys, the person entering it might have made a
> typo in the name (e.g.  smptpass) preventing it from being recognized as
> sensitive by the software, but easily recognizable as such by a human.
> 
> There's also the problem of varying opinions on what is considered as
> sensitive.  You mention credential information in URLs, but some people
> may consider the entire URL as something which they would not want to
> expose.
> 
> I think that attempting to do this would only result in a false sense of
> security.
> 


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: RFC: "git config -l" should not expose sensitive information

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Yeah. Thanks for a dose of sanity. I was really trying not to say "the
> given advice is bad, and we cannot help those people". But I think you
> are right; the only sensible path is for the user to inspect the output
> before posting it.

True.

Re: RFC: "git config -l" should not expose sensitive information

[Junio C Hamano]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> I think the problem is yet another step earlier: why do we build tools
> that encourage people to store passwords in plaintext in a configuration
> file that is by default world-readable?

True.  This particular one mentioned in the thread predates
credential helpers, so it is not faire to say "encourage".
We didn't and we don't.

Care to do a patch to deprecate sendemail.smtppass (i.e. give
warnings to users when it is used) and perhaps replace it with
something based on the credential store or something?

Re: RFC: "git config -l" should not expose sensitive information

[Andrew Ardill]

On 21 December 2012 02:49, Aaron Schrab <aaron@schrab.com> wrote:
> Tools outside of the core git tree may add support for new config keys which
> are meant to contain sensitive information, and there would be no way for
> `git config` to know about those.

I understand that we've come down mostly on the 'users must check
before sending' side of things, but this point isn't necessarily true.

It wouldn't be too hard to create a config setting with a list of
'sensitive' keys filled with sensible defaults. It would be the job of
the 3rd party to add the relevant keys to this config file. This
wouldn't help with old 3rd party tools but would provide a way to
'hide' things automatically. A user could of course configure this
themselves (though one would think most who knew how wouldn't need
to).

On 21 December 2012 02:52, Jeff King <peff@peff.net> wrote:
>> I think that attempting to do this would only result in a false sense
>> of security.
>
> Yeah. Thanks for a dose of sanity. I was really trying not to say "the
> given advice is bad, and we cannot help those people". But I think you
> are right; the only sensible path is for the user to inspect the output
> before posting it.

One thing that a new option could provide (or maybe even the existing
option if it detects an interactive session) is to prompt the user to
review the content before outputting it. This is a nice way of helping
users who don't know that there might be sensitive information in the
output. Are there any use cases where prompting the user would be
annoying when using this command?

Regards,

Andrew Ardill