RFC: "git config -l" should not expose sensitive information
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
At 10:04 -0500 20 Dec 2012, Jeff King 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
On Thu, Dec 20, 2012 at 10:49:15AM -0500, Aaron Schrab wrote: > At 10:04 -0500 20 Dec 2012, Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
yep - understood On 12/20/2012 04:49 PM, Aaron Schrab wrote: > At 10:04 -0500 20 Dec 2012, Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
Jeff King 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
Michael Haggerty 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
On 21 December 2012 02:49, Aaron Schrab 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 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
