{"thread":{"id":"32376","subject":"RFC: \"git config -l\" should not expose sensitive information","startedAt":"2012-12-17T11:35:54Z","lastAt":"2012-12-20T22:31:06Z","messageCount":10,"participants":["Toralf Förster","Jeff King","Aaron Schrab","Michael Haggerty","Junio C Hamano","Andrew Ardill"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"205048","messageId":"50CF039A.7010800@gmx.de","threadId":"32376","inReplyTo":null,"subject":"RFC: \"git config -l\" should not expose sensitive information","fromName":"Toralf Förster","fromEmail":"toralf.foerster@gmx.de","sentAt":"2012-12-17T11:35:54Z","receivedAt":"2012-12-17T11:35:54Z","isPatch":false,"sender":{"key":"toralf.foerster@gmx.de","avatar":null},"body":"often the output is requested in help forums - and a\n\"git config -l | wgetpaste\" exposes parameters like sendmail.smtppass -\nso hide those variables in the output (if not explicitly wanted) would\nmakes sense, or ?\n\n-- \nMfG/Sincerely\nToralf Förster\npgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3\n"},{"id":"205260","messageId":"20121220150408.GD27211@sigill.intra.peff.net","threadId":"32376","inReplyTo":"50CF039A.7010800@gmx.de","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-12-20T15:04:08Z","receivedAt":"2012-12-20T15:04:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 17, 2012 at 12:35:54PM +0100, Toralf Förster wrote:\n\n> often the output is requested in help forums - and a\n> \"git config -l | wgetpaste\" exposes parameters like sendmail.smtppass -\n> so hide those variables in the output (if not explicitly wanted) would\n> makes sense, or ?\n\nBut if we change \"git config -l\", won't that break all of the\nnon-exposing uses that rely on seeing all of the variables (e.g., it is\nperfectly fine for a porcelain to parse \"git config -l\" rather than\nmaking several calls to \"git config\"; IIRC, git-cola does this).\n\nThe problem seems to be that people are giving bad advice to tell people\nto post \"git config -l\" output without looking at. Maybe we could help\nthem with a \"git config --share-config\" option that dumps all config,\nbut sanitizes the output. It would need to have a list of sensitive keys\n(which does not exist yet), and would need to not just mark up things\nlike smtppass, but would also need to pull credential information out of\nremote.*.url strings. And maybe more (I haven't thought too long on it).\n\n-Peff\n"},{"id":"205264","messageId":"20121220154915.GA5162@pug.qqx.org","threadId":"32376","inReplyTo":"20121220150408.GD27211@sigill.intra.peff.net","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Aaron Schrab","fromEmail":"aaron@schrab.com","sentAt":"2012-12-20T15:49:15Z","receivedAt":"2012-12-20T15:49:15Z","isPatch":false,"sender":{"key":"aaron@schrab.com","avatar":"https://avatars.githubusercontent.com/u/39620?v=4"},"body":"At 10:04 -0500 20 Dec 2012, Jeff King <peff@peff.net> wrote:\n>The problem seems to be that people are giving bad advice to tell \n>people to post \"git config -l\" output without looking at. Maybe we \n>could help them with a \"git config --share-config\" option that dumps \n>all config, but sanitizes the output. It would need to have a list of \n>sensitive keys (which does not exist yet), and would need to not just \n>mark up things like smtppass, but would also need to pull credential \n>information out of remote.*.url strings. And maybe more (I haven't \n>thought too long on it).\n\nIf such an option is added, it is likely to cause more people to think \nthat there is no need to examine the output before sharing it.  But, I \ndon't think that the sanitizing could ever be sufficient to guarantee \nthat.\n\nTools outside of the core git tree may add support for new config keys \nwhich are meant to contain sensitive information, and there would be no \nway for `git config` to know about those.\n\nEven for known sensitive keys, the person entering it might have made a \ntypo in the name (e.g.  smptpass) preventing it from being recognized as \nsensitive by the software, but easily recognizable as such by a human.\n\nThere's also the problem of varying opinions on what is considered as \nsensitive.  You mention credential information in URLs, but some people \nmay consider the entire URL as something which they would not want to \nexpose.\n\nI think that attempting to do this would only result in a false sense of \nsecurity.\n"},{"id":"205265","messageId":"50D33409.1050309@alum.mit.edu","threadId":"32376","inReplyTo":"20121220150408.GD27211@sigill.intra.peff.net","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-12-20T15:51:37Z","receivedAt":"2012-12-20T15:51:37Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 12/20/2012 04:04 PM, Jeff King wrote:\n> On Mon, Dec 17, 2012 at 12:35:54PM +0100, Toralf Förster wrote:\n>> often the output is requested in help forums - and a\n>> \"git config -l | wgetpaste\" exposes parameters like sendmail.smtppass -\n>> so hide those variables in the output (if not explicitly wanted) would\n>> makes sense, or ?\n> \n> But if we change \"git config -l\", won't that break all of the\n> non-exposing uses that rely on seeing all of the variables (e.g., it is\n> perfectly fine for a porcelain to parse \"git config -l\" rather than\n> making several calls to \"git config\"; IIRC, git-cola does this).\n> \n> The problem seems to be that people are giving bad advice to tell people\n> to post \"git config -l\" output without looking at. Maybe we could help\n> them with a \"git config --share-config\" option that dumps all config,\n> but sanitizes the output. It would need to have a list of sensitive keys\n> (which does not exist yet), and would need to not just mark up things\n> like smtppass, but would also need to pull credential information out of\n> remote.*.url strings. And maybe more (I haven't thought too long on it).\n\nI think the problem is yet another step earlier: why do we build tools\nthat encourage people to store passwords in plaintext in a configuration\nfile that is by default world-readable?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"205266","messageId":"20121220155229.GA6008@sigill.intra.peff.net","threadId":"32376","inReplyTo":"20121220154915.GA5162@pug.qqx.org","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-12-20T15:52:30Z","receivedAt":"2012-12-20T15:52:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 20, 2012 at 10:49:15AM -0500, Aaron Schrab wrote:\n\n> At 10:04 -0500 20 Dec 2012, Jeff King <peff@peff.net> wrote:\n> >The problem seems to be that people are giving bad advice to tell\n> >people to post \"git config -l\" output without looking at. Maybe we\n> >could help them with a \"git config --share-config\" option that\n> >dumps all config, but sanitizes the output. It would need to have a\n> >list of sensitive keys (which does not exist yet), and would need\n> >to not just mark up things like smtppass, but would also need to\n> >pull credential information out of remote.*.url strings. And maybe\n> >more (I haven't thought too long on it).\n> \n> If such an option is added, it is likely to cause more people to\n> think that there is no need to examine the output before sharing it.\n> But, I don't think that the sanitizing could ever be sufficient to\n> guarantee that.\n> \n> Tools outside of the core git tree may add support for new config\n> keys which are meant to contain sensitive information, and there\n> would be no way for `git config` to know about those.\n\nGood point. I was a little on the fence already because any time you\nhave a \"prevent known bad\" list in a security setting, it is guaranteed\nto go out of date and screw you. But the presence of third-party tools\nmeans it does not even have to get out of date. It will always be\ncomplete.\n\n> I think that attempting to do this would only result in a false sense\n> of security.\n\nYeah. Thanks for a dose of sanity. I was really trying not to say \"the\ngiven advice is bad, and we cannot help those people\". But I think you\nare right; the only sensible path is for the user to inspect the output\nbefore posting it.\n\n-Peff\n"},{"id":"205267","messageId":"20121220155444.GB6008@sigill.intra.peff.net","threadId":"32376","inReplyTo":"50D33409.1050309@alum.mit.edu","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-12-20T15:54:44Z","receivedAt":"2012-12-20T15:54:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 20, 2012 at 04:51:37PM +0100, Michael Haggerty wrote:\n\n> > The problem seems to be that people are giving bad advice to tell people\n> > to post \"git config -l\" output without looking at. Maybe we could help\n> > them with a \"git config --share-config\" option that dumps all config,\n> > but sanitizes the output. It would need to have a list of sensitive keys\n> > (which does not exist yet), and would need to not just mark up things\n> > like smtppass, but would also need to pull credential information out of\n> > remote.*.url strings. And maybe more (I haven't thought too long on it).\n> \n> I think the problem is yet another step earlier: why do we build tools\n> that encourage people to store passwords in plaintext in a configuration\n> file that is by default world-readable?\n\nAgreed. Most of it is hysterical raisins. We did not have any portable\nsecure storage for a long time. These days we have the credential helper\nsubsystem, which send-email can and should be using.\n\n-Peff\n"},{"id":"205269","messageId":"50D33AE1.4020604@gmx.de","threadId":"32376","inReplyTo":"20121220154915.GA5162@pug.qqx.org","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Toralf Förster","fromEmail":"toralf.foerster@gmx.de","sentAt":"2012-12-20T16:20:49Z","receivedAt":"2012-12-20T16:20:49Z","isPatch":false,"sender":{"key":"toralf.foerster@gmx.de","avatar":null},"body":"yep - understood\n\n\nOn 12/20/2012 04:49 PM, Aaron Schrab wrote:\n> At 10:04 -0500 20 Dec 2012, Jeff King <peff@peff.net> wrote:\n>> The problem seems to be that people are giving bad advice to tell\n>> people to post \"git config -l\" output without looking at. Maybe we\n>> could help them with a \"git config --share-config\" option that dumps\n>> all config, but sanitizes the output. It would need to have a list of\n>> sensitive keys (which does not exist yet), and would need to not just\n>> mark up things like smtppass, but would also need to pull credential\n>> information out of remote.*.url strings. And maybe more (I haven't\n>> thought too long on it).\n> \n> If such an option is added, it is likely to cause more people to think\n> that there is no need to examine the output before sharing it.  But, I\n> don't think that the sanitizing could ever be sufficient to guarantee that.\n> \n> Tools outside of the core git tree may add support for new config keys\n> which are meant to contain sensitive information, and there would be no\n> way for `git config` to know about those.\n> \n> Even for known sensitive keys, the person entering it might have made a\n> typo in the name (e.g.  smptpass) preventing it from being recognized as\n> sensitive by the software, but easily recognizable as such by a human.\n> \n> There's also the problem of varying opinions on what is considered as\n> sensitive.  You mention credential information in URLs, but some people\n> may consider the entire URL as something which they would not want to\n> expose.\n> \n> I think that attempting to do this would only result in a false sense of\n> security.\n> \n\n\n-- \nMfG/Sincerely\nToralf Förster\npgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3\n"},{"id":"205281","messageId":"7vfw306048.fsf@alter.siamese.dyndns.org","threadId":"32376","inReplyTo":"20121220155229.GA6008@sigill.intra.peff.net","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-20T18:37:27Z","receivedAt":"2012-12-20T18:37:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Yeah. Thanks for a dose of sanity. I was really trying not to say \"the\n> given advice is bad, and we cannot help those people\". But I think you\n> are right; the only sensible path is for the user to inspect the output\n> before posting it.\n\nTrue.\n"},{"id":"205282","messageId":"7vbodo5zjj.fsf@alter.siamese.dyndns.org","threadId":"32376","inReplyTo":"50D33409.1050309@alum.mit.edu","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-20T18:49:52Z","receivedAt":"2012-12-20T18:49:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> I think the problem is yet another step earlier: why do we build tools\n> that encourage people to store passwords in plaintext in a configuration\n> file that is by default world-readable?\n\nTrue.  This particular one mentioned in the thread predates\ncredential helpers, so it is not faire to say \"encourage\".\nWe didn't and we don't.\n\nCare to do a patch to deprecate sendemail.smtppass (i.e. give\nwarnings to users when it is used) and perhaps replace it with\nsomething based on the credential store or something?\n"},{"id":"205299","messageId":"CAH5451kjsfvye8PEBN7DGzA+auLDJEmJb2qAqcD9MX9MVAu4NQ@mail.gmail.com","threadId":"32376","inReplyTo":"7vbodo5zjj.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: \"git config -l\" should not expose sensitive information","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-12-20T22:31:06Z","receivedAt":"2012-12-20T22:31:06Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 21 December 2012 02:49, Aaron Schrab <aaron@schrab.com> wrote:\n> Tools outside of the core git tree may add support for new config keys which\n> are meant to contain sensitive information, and there would be no way for\n> `git config` to know about those.\n\nI understand that we've come down mostly on the 'users must check\nbefore sending' side of things, but this point isn't necessarily true.\n\nIt wouldn't be too hard to create a config setting with a list of\n'sensitive' keys filled with sensible defaults. It would be the job of\nthe 3rd party to add the relevant keys to this config file. This\nwouldn't help with old 3rd party tools but would provide a way to\n'hide' things automatically. A user could of course configure this\nthemselves (though one would think most who knew how wouldn't need\nto).\n\nOn 21 December 2012 02:52, Jeff King <peff@peff.net> wrote:\n>> I think that attempting to do this would only result in a false sense\n>> of security.\n>\n> Yeah. Thanks for a dose of sanity. I was really trying not to say \"the\n> given advice is bad, and we cannot help those people\". But I think you\n> are right; the only sensible path is for the user to inspect the output\n> before posting it.\n\nOne thing that a new option could provide (or maybe even the existing\noption if it detects an interactive session) is to prompt the user to\nreview the content before outputting it. This is a nice way of helping\nusers who don't know that there might be sensitive information in the\noutput. Are there any use cases where prompting the user would be\nannoying when using this command?\n\nRegards,\n\nAndrew Ardill\n"}]}