{"thread":{"id":"42399","subject":"[Opinion gathering] Git remote whitelist/blacklist","startedAt":"2016-05-20T14:21:44Z","lastAt":"2016-05-25T22:52:14Z","messageCount":15,"participants":["Francois Beutin","Randall S. Becker","Lars Schneider","Matthieu Moy","Junio C Hamano","Aaron Schrab","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"287087","messageId":"584027154.5608416.1463754104066.JavaMail.zimbra@ensimag.grenoble-inp.fr","threadId":"42399","inReplyTo":"1040142021.5607762.1463753271105.JavaMail.zimbra@ensimag.grenoble-inp.fr","subject":"[Opinion gathering] Git remote whitelist/blacklist","fromName":"Francois Beutin","fromEmail":"beutinf@ensimag.grenoble-inp.fr","sentAt":"2016-05-20T14:21:44Z","receivedAt":"2016-05-20T14:21:44Z","isPatch":false,"sender":{"key":"beutinf@ensimag.grenoble-inp.fr","avatar":null},"body":"Hi everyone,\n\nWe (Ensimag students) plan to implement the\n\"remote whitelist/blacklist\" feature described in the SoC 2016 ideas,\nbut first I would like to be sure we agree on what exactly this\nfeature would be, and that the community sees an interest in it.\n\nThe general idea is to add a way to prevent accidental push to the\nwrong repository, we see two ways to do it:\nFirst solution:\n - a whitelist: Git will accept a push to a repository in it\n - a blacklist: Git will refuse a push to a repository in it\n - a default policy\n\nSecond solution:\n - a default policy\n - a list of repository not following the default policy\n\nThe new options in config if we implement the first solution:\n\n[remote]\n\t# List of repository that will be allowed/denied with\n\t\t\t\t\t# a whitelist/blacklist\n\twhitelisted = \"http://git-hosting.org\"\n\tblacklisted = \"http://git-hosting2.org\"\n\n\t# What is displayed when the user attempts a push on an\n\t\t# unauthorised repository? (this option overwrites\n\t\t# the default message)\n\tdenymessage = \"message\"\n\n\t# What git should do if the user attempts a push on an\n\t\t# unauthorised repository (reject or warn and\n\t\t# ask the user)?\n\tdenypolicy = reject(default)/warning\n\n\t# How should unknown repositories be treated?\n\tdefaultpolicy = allow(default)/deny\n\n\nSome concrete usage example:\n\n - A beginner is working on company code, to prevent him from\n\taccidentally pushing the code on a public repository, the\n\tcompany (or him) can do:\ngit config --global remote.defaultpolicy \"deny\"\ngit config --global remote.denymessage \"Not the company's server!\"\ngit config --global remote.denypolicy \"reject\"\ngit config --global remote.whitelisted \"http://company-server.com\"\n\n\n - A regular git user fears that he might accidentally push sensible\n\tcode to a public repository he often uses for free-time\n\tprojects, he can do:\ngit config remote.defaultpolicy \"allow\"\t#not really needed\ngit config remote.denymessage \"Are you sure it is the good server?\"\ngit config remote.denypolicy \"warning\"\ngit config remote.blacklisted \"http://github/personnalproject\"\n\n\nWe would like to gather opinions about this before starting to\n\timplement it, is there any controversy? Do you prefer the\n\tfirst or second solution (or none)? Do you find the option's\n\tnames accurate?\n"},{"id":"287090","messageId":"001001d1b2a3$06d7bbb0$14873310$@nexbridge.com","threadId":"42399","inReplyTo":"584027154.5608416.1463754104066.JavaMail.zimbra@ensimag.grenoble-inp.fr","subject":"RE: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2016-05-20T14:22:17Z","receivedAt":"2016-05-20T14:22:17Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 20, 2016 10:22 AM, Francois Beutin wrote:\n> We (Ensimag students) plan to implement the \"remote whitelist/blacklist\"\n> feature described in the SoC 2016 ideas, but first I would like to be sure we\n> agree on what exactly this feature would be, and that the community sees an\n> interest in it.\n> \n> The general idea is to add a way to prevent accidental push to the wrong\n> repository, we see two ways to do it:\n> First solution:\n> - a whitelist: Git will accept a push to a repository in it\n> - a blacklist: Git will refuse a push to a repository in it\n> - a default policy\n> \n> Second solution:\n> - a default policy\n> - a list of repository not following the default policy\n> \n> The new options in config if we implement the first solution:\n> \n> [remote]\n> \t# List of repository that will be allowed/denied with\n> \t\t\t\t\t# a whitelist/blacklist\n> \twhitelisted = \"http://git-hosting.org\"\n> \tblacklisted = \"http://git-hosting2.org\"\n> \n> \t# What is displayed when the user attempts a push on an\n> \t\t# unauthorised repository? (this option overwrites\n> \t\t# the default message)\n> \tdenymessage = \"message\"\n> \n> \t# What git should do if the user attempts a push on an\n> \t\t# unauthorised repository (reject or warn and\n> \t\t# ask the user)?\n> \tdenypolicy = reject(default)/warning\n> \n> \t# How should unknown repositories be treated?\n> \tdefaultpolicy = allow(default)/deny\n> \n> \n> Some concrete usage example:\n> \n> - A beginner is working on company code, to prevent him from\n> \taccidentally pushing the code on a public repository, the\n> \tcompany (or him) can do:\n> git config --global remote.defaultpolicy \"deny\"\n> git config --global remote.denymessage \"Not the company's server!\"\n> git config --global remote.denypolicy \"reject\"\n> git config --global remote.whitelisted \"http://company-server.com\"\n> \n> \n> - A regular git user fears that he might accidentally push sensible\n> \tcode to a public repository he often uses for free-time\n> \tprojects, he can do:\n> git config remote.defaultpolicy \"allow\"\t#not really needed\n> git config remote.denymessage \"Are you sure it is the good server?\"\n> git config remote.denypolicy \"warning\"\n> git config remote.blacklisted \"http://github/personnalproject\"\n> \n> \n> We would like to gather opinions about this before starting to\n> \timplement it, is there any controversy? Do you prefer the\n> \tfirst or second solution (or none)? Do you find the option's\n> \tnames accurate?\n\nHow would this feature be secure and made reliably consistent in managing the policies (I do like storing the lists separate from the repository, btw)? My concern is that by using git config, a legitimate clone can be made of a repository with these attributes, then the attributes overridden by local config on the clone turning the policy off, changing the remote, and thereby allowing a push to an unauthorized destination (example: one on the originally intended blacklist). It is unclear to me how a policy manager would keep track of this or even know this happened and prevent policies from being bypassed - could you clarify this for the requirements?\n\nCheers,\nRandall\n\n-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)\n-- In my real life, I talk too much.\n"},{"id":"287240","messageId":"1929221963.5686879.1464007899902.JavaMail.zimbra@ensimag.grenoble-inp.fr","threadId":"42399","inReplyTo":"001001d1b2a3$06d7bbb0$14873310$@nexbridge.com","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Francois Beutin","fromEmail":"beutinf@ensimag.grenoble-inp.fr","sentAt":"2016-05-23T12:51:39Z","receivedAt":"2016-05-23T12:51:39Z","isPatch":false,"sender":{"key":"beutinf@ensimag.grenoble-inp.fr","avatar":null},"body":"I agree that we cannot have a completly secure and reliable \nway to forbid a push to the wrong remote. This is not what\nour feature is trying to do, we assume that if a programmer \ntweaks his config file and changes the rules he knows what\nhe is doing and we won't try to prevent it.\nOur goal is to implement a safeguard against accidental push,\nthe feature will work only if the programmer wants it to.\n\n----- Mail original -----\n> De: \"Randall S. Becker\" \n> À: \"Francois Beutin\" , git@vger.kernel.org\n> Cc: \"matthieu moy\" , \"simon rabourg\" , \"wiliam\n> duclot\" , \"antoine queru\" \n> Envoyé: Vendredi 20 Mai 2016 16:22:17\n> Objet: RE: [Opinion gathering] Git remote whitelist/blacklist\n> \n> On May 20, 2016 10:22 AM, Francois Beutin wrote:\n> > We (Ensimag students) plan to implement the \"remote whitelist/blacklist\"\n> > feature described in the SoC 2016 ideas, but first I would like to be sure\n> > we\n> > agree on what exactly this feature would be, and that the community sees an\n> > interest in it.\n> > \n> > The general idea is to add a way to prevent accidental push to the wrong\n> > repository, we see two ways to do it:\n> > First solution:\n> > - a whitelist: Git will accept a push to a repository in it\n> > - a blacklist: Git will refuse a push to a repository in it\n> > - a default policy\n> > \n> > Second solution:\n> > - a default policy\n> > - a list of repository not following the default policy\n> > \n> > The new options in config if we implement the first solution:\n> > \n> > [remote]\n> > \t# List of repository that will be allowed/denied with\n> > \t\t\t\t\t# a whitelist/blacklist\n> > \twhitelisted = \"http://git-hosting.org\"\n> > \tblacklisted = \"http://git-hosting2.org\"\n> > \n> > \t# What is displayed when the user attempts a push on an\n> > \t\t# unauthorised repository? (this option overwrites\n> > \t\t# the default message)\n> > \tdenymessage = \"message\"\n> > \n> > \t# What git should do if the user attempts a push on an\n> > \t\t# unauthorised repository (reject or warn and\n> > \t\t# ask the user)?\n> > \tdenypolicy = reject(default)/warning\n> > \n> > \t# How should unknown repositories be treated?\n> > \tdefaultpolicy = allow(default)/deny\n> > \n> > \n> > Some concrete usage example:\n> > \n> > - A beginner is working on company code, to prevent him from\n> > \taccidentally pushing the code on a public repository, the\n> > \tcompany (or him) can do:\n> > git config --global remote.defaultpolicy \"deny\"\n> > git config --global remote.denymessage \"Not the company's server!\"\n> > git config --global remote.denypolicy \"reject\"\n> > git config --global remote.whitelisted \"http://company-server.com\"\n> > \n> > \n> > - A regular git user fears that he might accidentally push sensible\n> > \tcode to a public repository he often uses for free-time\n> > \tprojects, he can do:\n> > git config remote.defaultpolicy \"allow\"\t#not really needed\n> > git config remote.denymessage \"Are you sure it is the good server?\"\n> > git config remote.denypolicy \"warning\"\n> > git config remote.blacklisted \"http://github/personnalproject\"\n> > \n> > \n> > We would like to gather opinions about this before starting to\n> > \timplement it, is there any controversy? Do you prefer the\n> > \tfirst or second solution (or none)? Do you find the option's\n> > \tnames accurate?\n> \n> How would this feature be secure and made reliably consistent in managing the\n> policies (I do like storing the lists separate from the repository, btw)? My\n> concern is that by using git config, a legitimate clone can be made of a\n> repository with these attributes, then the attributes overridden by local\n> config on the clone turning the policy off, changing the remote, and thereby\n> allowing a push to an unauthorized destination (example: one on the\n> originally intended blacklist). It is unclear to me how a policy manager\n> would keep track of this or even know this happened and prevent policies\n> from being bypassed - could you clarify this for the requirements?\n> \n> Cheers,\n> Randall\n> \n> -- Brief whoami: NonStop&UNIX developer since approximately\n> UNIX(421664400)/NonStop(211288444200000000)\n> -- In my real life, I talk too much.\n> \n> \n> \n> \n"},{"id":"287402","messageId":"1884904685.12056.1464084750628.JavaMail.zimbra@ensimag.grenoble-inp.fr","threadId":"42399","inReplyTo":"1929221963.5686879.1464007899902.JavaMail.zimbra@ensimag.grenoble-inp.fr","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Francois Beutin","fromEmail":"beutinf@ensimag.grenoble-inp.fr","sentAt":"2016-05-24T10:12:30Z","receivedAt":"2016-05-24T10:12:30Z","isPatch":false,"sender":{"key":"beutinf@ensimag.grenoble-inp.fr","avatar":null},"body":"> > > On May 20, 2016 10:22 AM, Francois Beutin wrote:\n> > > We (Ensimag students) plan to implement the \"remote whitelist/blacklist\"\n> > > feature described in the SoC 2016 ideas, but first I would like to be\n> > > sure\n> > > we\n> > > agree on what exactly this feature would be, and that the community sees\n> > > an\n> > > interest in it.\n> > > \n> > > The general idea is to add a way to prevent accidental push to the wrong\n> > > repository, we see two ways to do it:\n> > > First solution:\n> > > - a whitelist: Git will accept a push to a repository in it\n> > > - a blacklist: Git will refuse a push to a repository in it\n> > > - a default policy\n> > > \n> > > Second solution:\n> > > - a default policy\n> > > - a list of repository not following the default policy\n> > > \n> > > The new options in config if we implement the first solution:\n> > > \n> > > [remote]\n> > > \t# List of repository that will be allowed/denied with\n> > > \t\t\t\t\t# a whitelist/blacklist\n> > > \twhitelisted = \"http://git-hosting.org\"\n> > > \tblacklisted = \"http://git-hosting2.org\"\n> > > \n> > > \t# What is displayed when the user attempts a push on an\n> > > \t\t# unauthorised repository? (this option overwrites\n> > > \t\t# the default message)\n> > > \tdenymessage = \"message\"\n> > > \n> > > \t# What git should do if the user attempts a push on an\n> > > \t\t# unauthorised repository (reject or warn and\n> > > \t\t# ask the user)?\n> > > \tdenypolicy = reject(default)/warning\n> > > \n> > > \t# How should unknown repositories be treated?\n> > > \tdefaultpolicy = allow(default)/deny\n> > > \n> > > \n> > > Some concrete usage example:\n> > > \n> > > - A beginner is working on company code, to prevent him from\n> > > \taccidentally pushing the code on a public repository, the\n> > > \tcompany (or him) can do:\n> > > git config --global remote.defaultpolicy \"deny\"\n> > > git config --global remote.denymessage \"Not the company's server!\"\n> > > git config --global remote.denypolicy \"reject\"\n> > > git config --global remote.whitelisted \"http://company-server.com\"\n> > > \n> > > \n> > > - A regular git user fears that he might accidentally push sensible\n> > > \tcode to a public repository he often uses for free-time\n> > > \tprojects, he can do:\n> > > git config remote.defaultpolicy \"allow\"\t#not really needed\n> > > git config remote.denymessage \"Are you sure it is the good server?\"\n> > > git config remote.denypolicy \"warning\"\n> > > git config remote.blacklisted \"http://github/personnalproject\"\n> > > \n> > > \n> > > We would like to gather opinions about this before starting to\n> > > \timplement it, is there any controversy? Do you prefer the\n> > > \tfirst or second solution (or none)? Do you find the option's\n> > > \tnames accurate?\n> > \n> > How would this feature be secure and made reliably consistent in managing\n> > the\n> > policies (I do like storing the lists separate from the repository, btw)?\n> > My\n> > concern is that by using git config, a legitimate clone can be made of a\n> > repository with these attributes, then the attributes overridden by local\n> > config on the clone turning the policy off, changing the remote, and\n> > thereby\n> > allowing a push to an unauthorized destination (example: one on the\n> > originally intended blacklist). It is unclear to me how a policy manager\n> > would keep track of this or even know this happened and prevent policies\n> > from being bypassed - could you clarify this for the requirements?\n> > \n> > Cheers,\n> > Randall\n> > \n> > -- Brief whoami: NonStop&UNIX developer since approximately\n> > UNIX(421664400)/NonStop(211288444200000000)\n> > -- In my real life, I talk too much.\n> > \n> \n> I agree that we cannot have a completly secure and reliable\n> way to forbid a push to the wrong remote. This is not what\n> our feature is trying to do, we assume that if a programmer\n> tweaks his config file and changes the rules he knows what\n> he is doing and we won't try to prevent it.\n> Our goal is to implement a safeguard against accidental push,\n> the feature will work only if the programmer wants it to.\n\n\nIn the end we decided to implement the first solution described\nabove.\nWe chose this version because we think there could have been\nconflicts between the global and local config files. Moreover, we\nthink using two different lists for denied/allowed remotes is more\nintuitive and user-friendly, and it will allow the user to use\n\"advanced\" options such as:\ndenied = \"http://git-hosting.org\"\nallowed = \"http://git-hosting.org/exception-repo\"\nto deny a push to git-hosting.org EXCEPT to git-hosting.org/\n\t\t\t\t\t\texception-repo\n\nWe are unsure about the behavior to adopt in case of a conflicting\nconfig file (for example a remote is in both the allowed and the\ndenied lists). The programm would print a warning message and:\n\t\t- follow the defaultpolicy\n\tOR\t- ask for confirmation\n\tOR\t- reject the push\nAs of now we are inclined to implement the \"ask for confirmation\"\noption.\n"},{"id":"287405","messageId":"84BDC4A4-FBE1-4542-868C-FA77A25469F3@gmail.com","threadId":"42399","inReplyTo":"1884904685.12056.1464084750628.JavaMail.zimbra@ensimag.grenoble-inp.fr","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-05-24T10:55:31Z","receivedAt":"2016-05-24T10:55:31Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 24 May 2016, at 06:12, Francois Beutin wrote:\n> \n>>>> On May 20, 2016 10:22 AM, Francois Beutin wrote:\n>>>> We (Ensimag students) plan to implement the \"remote whitelist/blacklist\"\n>>>> feature described in the SoC 2016 ideas, but first I would like to be\n>>>> sure\n>>>> we\n>>>> agree on what exactly this feature would be, and that the community sees\n>>>> an\n>>>> interest in it.\n>>>> \n>>>> The general idea is to add a way to prevent accidental push to the wrong\n>>>> repository, we see two ways to do it:\n>>>> First solution:\n>>>> - a whitelist: Git will accept a push to a repository in it\n>>>> - a blacklist: Git will refuse a push to a repository in it\n>>>> - a default policy\n>>>> \n>>>> Second solution:\n>>>> - a default policy\n>>>> - a list of repository not following the default policy\n>>>> \n>>>> The new options in config if we implement the first solution:\n>>>> \n>>>> [remote]\n>>>> \t# List of repository that will be allowed/denied with\n>>>> \t\t\t\t\t# a whitelist/blacklist\n>>>> \twhitelisted = \"http://git-hosting.org\"\n>>>> \tblacklisted = \"http://git-hosting2.org\"\n>>>> \n>>>> \t# What is displayed when the user attempts a push on an\n>>>> \t\t# unauthorised repository? (this option overwrites\n>>>> \t\t# the default message)\n>>>> \tdenymessage = \"message\"\n>>>> \n>>>> \t# What git should do if the user attempts a push on an\n>>>> \t\t# unauthorised repository (reject or warn and\n>>>> \t\t# ask the user)?\n>>>> \tdenypolicy = reject(default)/warning\n>>>> \n>>>> \t# How should unknown repositories be treated?\n>>>> \tdefaultpolicy = allow(default)/deny\n>>>> \n>>>> \n>>>> Some concrete usage example:\n>>>> \n>>>> - A beginner is working on company code, to prevent him from\n>>>> \taccidentally pushing the code on a public repository, the\n>>>> \tcompany (or him) can do:\n>>>> git config --global remote.defaultpolicy \"deny\"\n>>>> git config --global remote.denymessage \"Not the company's server!\"\n>>>> git config --global remote.denypolicy \"reject\"\n>>>> git config --global remote.whitelisted \"http://company-server.com\"\n>>>> \n>>>> \n>>>> - A regular git user fears that he might accidentally push sensible\n>>>> \tcode to a public repository he often uses for free-time\n>>>> \tprojects, he can do:\n>>>> git config remote.defaultpolicy \"allow\"\t#not really needed\n>>>> git config remote.denymessage \"Are you sure it is the good server?\"\n>>>> git config remote.denypolicy \"warning\"\n>>>> git config remote.blacklisted \"http://github/personnalproject\"\n>>>> \n>>>> \n>>>> We would like to gather opinions about this before starting to\n>>>> \timplement it, is there any controversy? Do you prefer the\n>>>> \tfirst or second solution (or none)? Do you find the option's\n>>>> \tnames accurate?\n>>> \n>>> How would this feature be secure and made reliably consistent in managing\n>>> the\n>>> policies (I do like storing the lists separate from the repository, btw)?\n>>> My\n>>> concern is that by using git config, a legitimate clone can be made of a\n>>> repository with these attributes, then the attributes overridden by local\n>>> config on the clone turning the policy off, changing the remote, and\n>>> thereby\n>>> allowing a push to an unauthorized destination (example: one on the\n>>> originally intended blacklist). It is unclear to me how a policy manager\n>>> would keep track of this or even know this happened and prevent policies\n>>> from being bypassed - could you clarify this for the requirements?\n>>> \n>>> Cheers,\n>>> Randall\n>>> \n>>> -- Brief whoami: NonStop&UNIX developer since approximately\n>>> UNIX(421664400)/NonStop(211288444200000000)\n>>> -- In my real life, I talk too much.\n>>> \n>> \n>> I agree that we cannot have a completly secure and reliable\n>> way to forbid a push to the wrong remote. This is not what\n>> our feature is trying to do, we assume that if a programmer\n>> tweaks his config file and changes the rules he knows what\n>> he is doing and we won't try to prevent it.\n>> Our goal is to implement a safeguard against accidental push,\n>> the feature will work only if the programmer wants it to.\n> \n> \n> In the end we decided to implement the first solution described\n> above.\n> We chose this version because we think there could have been\n> conflicts between the global and local config files. Moreover, we\n> think using two different lists for denied/allowed remotes is more\n> intuitive and user-friendly, and it will allow the user to use\n> \"advanced\" options such as:\n> denied = \"http://git-hosting.org\"\n> allowed = \"http://git-hosting.org/exception-repo\"\n> to deny a push to git-hosting.org EXCEPT to git-hosting.org/\n> \t\t\t\t\t\texception-repo\n> \n> We are unsure about the behavior to adopt in case of a conflicting\n> config file (for example a remote is in both the allowed and the\n> denied lists). The programm would print a warning message and:\n> \t\t- follow the defaultpolicy\n> \tOR\t- ask for confirmation\n> \tOR\t- reject the push\n> As of now we are inclined to implement the \"ask for confirmation\"\n> option.\n\nFirst of all: thanks for picking up the idea and working on the feature!\nI proposed the idea for GSoC and I am glad you CC'ed me because otherwise \nI would have missed that you are working on it :-)\n\nAs you already stated correctly to Randall: this \"protection\" can never\nbe completely secure as you can always override Git config settings. \nIt is more a \"hint\" to protect inexperienced Git users. Therefore I would\nmake the default as conservative as possible. To answer your question,\nI would reject the push (because the remote is in the denied list) and\nprint a warning to point out the conflicting configs to the user.\n\nCheers,\nLars\n"},{"id":"287414","messageId":"vpq37p74nu1.fsf@anie.imag.fr","threadId":"42399","inReplyTo":"84BDC4A4-FBE1-4542-868C-FA77A25469F3@gmail.com","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-05-24T12:55:50Z","receivedAt":"2016-05-24T12:55:50Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Lars Schneider writes:\n\n> To answer your question,\n> I would reject the push (because the remote is in the denied list) and\n> print a warning to point out the conflicting configs to the user.\n\nSo, when trying a forbidden push, Git would deny it and the only way to\nforce the push would be to remove the blacklist from the config, right?\n\nProbably the sanest way to go. I thought about adding a \"git push\n--force-even-if-in-blacklist\" or so, but I don't think the feature\ndeserves one specific option (hence add some noise in `git push -h`).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"287419","messageId":"CAPc5daURo8SkbeGf0MEsp0sLzdzFfUOxptgusFr58UG9SKmDAA@mail.gmail.com","threadId":"42399","inReplyTo":"vpq37p74nu1.fsf@anie.imag.fr","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-24T16:07:53Z","receivedAt":"2016-05-24T16:07:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy\n wrote:\n> So, when trying a forbidden push, Git would deny it and the only way to\n> force the push would be to remove the blacklist from the config, right?\n>\n> Probably the sanest way to go. I thought about adding a \"git push\n> --force-even-if-in-blacklist\" or so, but I don't think the feature\n> deserves one specific option (hence add some noise in `git push -h`).\n\nYeah, I agree --even-if-in-blacklist is a road to madness, but I wonder\nhow this is different from setting pushURL to /dev/null or something\nillegal and replace that phony configuration value when you really need\nto push?\n"},{"id":"287420","messageId":"002b01d1b5d7$aefd0a70$0cf71f50$@nexbridge.com","threadId":"42399","inReplyTo":"CAPc5daURo8SkbeGf0MEsp0sLzdzFfUOxptgusFr58UG9SKmDAA@mail.gmail.com","subject":"RE: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2016-05-24T16:16:46Z","receivedAt":"2016-05-24T16:16:46Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 24, 2016 12:08 PM, Matthieu Moy wrote:\n> > So, when trying a forbidden push, Git would deny it and the only way\n> > to force the push would be to remove the blacklist from the config, right?\n> >\n> > Probably the sanest way to go. I thought about adding a \"git push\n> > --force-even-if-in-blacklist\" or so, but I don't think the feature\n> > deserves one specific option (hence add some noise in `git push -h`).\n> \n> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder how\n> this is different from setting pushURL to /dev/null or something illegal and\n> replace that phony configuration value when you really need to push?\n\nMay be missing the point, but isn't the original intent to provide policy-based to control the push destinations? A sufficiently knowledgeable person, being a couple of weeks into git, would easily see that the config points to a black-listed destination and easily bypass it with a config update, rendering all this pointless? This seems to me to be a lot of effort to go to for limited value - unless immutable attributes are going to be obtained from the upstream repository - which also seems to run counter to the whole point.\n\nConfusededly,\nRandall\n"},{"id":"287421","messageId":"CAPc5daUTdesKcddPRtQDwO+L+qxEiE5NFv5_=2wyOH-QQ5uO1Q@mail.gmail.com","threadId":"42399","inReplyTo":"002b01d1b5d7$aefd0a70$0cf71f50$@nexbridge.com","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-24T16:20:42Z","receivedAt":"2016-05-24T16:20:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, May 24, 2016 at 9:16 AM, Randall S. Becker\n wrote:\n> May be missing the point, but isn't the original intent to provide policy-based to control the push\n\nI didn't get the impression that those who are proposing were\ninterested in a \"policy that you have to obey\" at all. Isn't this more\nabout \"I often by mistake say 'git push foo' which I want to prevent\"?\nAt least that was the impression I was getting.\n"},{"id":"287443","messageId":"B559ECA4-0C95-4E40-8E2C-22299614E559@gmail.com","threadId":"42399","inReplyTo":"CAPc5daURo8SkbeGf0MEsp0sLzdzFfUOxptgusFr58UG9SKmDAA@mail.gmail.com","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-05-24T19:11:02Z","receivedAt":"2016-05-24T19:11:02Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 24 May 2016, at 12:07, Junio C Hamano wrote:\n> \n> On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy\n> wrote:\n>> So, when trying a forbidden push, Git would deny it and the only way to\n>> force the push would be to remove the blacklist from the config, right?\n>> \n>> Probably the sanest way to go. I thought about adding a \"git push\n>> --force-even-if-in-blacklist\" or so, but I don't think the feature\n>> deserves one specific option (hence add some noise in `git push -h`).\n> \n> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder\n> how this is different from setting pushURL to /dev/null or something\n> illegal and replace that phony configuration value when you really need\n> to push?\nIt is no different from changing the push URL. As a matter of fact, that\nis how I've implemented this \"blacklist\" feature with the current version\nof Git:\nhttps://speakerdeck.com/larsxschneider/git-at-scale?slide=35\n\n- Lars\n"},{"id":"287446","messageId":"vpqa8jfmfb4.fsf@anie.imag.fr","threadId":"42399","inReplyTo":"CAPc5daURo8SkbeGf0MEsp0sLzdzFfUOxptgusFr58UG9SKmDAA@mail.gmail.com","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-05-24T19:22:39Z","receivedAt":"2016-05-24T19:22:39Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy\n> wrote:\n>> So, when trying a forbidden push, Git would deny it and the only way to\n>> force the push would be to remove the blacklist from the config, right?\n>>\n>> Probably the sanest way to go. I thought about adding a \"git push\n>> --force-even-if-in-blacklist\" or so, but I don't think the feature\n>> deserves one specific option (hence add some noise in `git push -h`).\n>\n> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder\n> how this is different from setting pushURL to /dev/null or something\n> illegal and replace that phony configuration value when you really need\n> to push?\n\nChanging pushURL is something you can do per-repo, but the\nwhitelist/blacklist could be done user-wide or even system-wide\n(typically, if the sysadmin has control on everybody's /etc/gitconfig,\nthere can be a default policy to prevent accidental push to some URLs).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"287447","messageId":"166C4E9F-6231-47ED-88F3-EAD95DEE7DF2@gmail.com","threadId":"42399","inReplyTo":"002b01d1b5d7$aefd0a70$0cf71f50$@nexbridge.com","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-05-24T19:25:12Z","receivedAt":"2016-05-24T19:25:12Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 24 May 2016, at 12:16, Randall S. Becker wrote:\n> \n> On May 24, 2016 12:08 PM, Matthieu Moy wrote:\n>>> So, when trying a forbidden push, Git would deny it and the only way\n>>> to force the push would be to remove the blacklist from the config, right?\n>>> \n>>> Probably the sanest way to go. I thought about adding a \"git push\n>>> --force-even-if-in-blacklist\" or so, but I don't think the feature\n>>> deserves one specific option (hence add some noise in `git push -h`).\n>> \n>> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder how\n>> this is different from setting pushURL to /dev/null or something illegal and\n>> replace that phony configuration value when you really need to push?\n> \n> May be missing the point, but isn't the original intent to provide policy-based to control the push destinations? A sufficiently knowledgeable person, being a couple of weeks into git, would easily see that the config points to a black-listed destination and easily bypass it with a config update, rendering all this pointless? This seems to me to be a lot of effort to go to for limited value - unless immutable attributes are going to be obtained from the upstream repository - which also seems to run counter to the whole point.\n\nAn actor with a bad intent will *always* be able to bypass this. However, I see two use cases:\n\n(1) Accidental pushes. \nAn inexpierenced developer clones a repo from github.com, commits for whatever reason company code and pushes. At this point the code leaked. The blacklist feature could have warned/stopped the developer.\n\n(2) Intentional open source pushes.\nAt my day job we encourage people to contribute to open source. However, we want them to follow our open source contribution process. If they run \"git push\" on a new github.com repo then I want to interrupt the push and tell them to look at our contribution guidelines. Afterwards they could whitelist the repo on their local machine and push without trouble.\n\nIn summary I think the feature could be a safety net for the developer to not leak company code.\n\nCheers,\nLars"},{"id":"287453","messageId":"005601d1b5ff$90f442f0$b2dcc8d0$@nexbridge.com","threadId":"42399","inReplyTo":"166C4E9F-6231-47ED-88F3-EAD95DEE7DF2@gmail.com","subject":"RE: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2016-05-24T21:02:16Z","receivedAt":"2016-05-24T21:02:16Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 24, 2016 3:25 PM Lars Schneider wrote:\n> > On 24 May 2016, at 12:16, Randall S. Becker \n> wrote:\n> >\n> > On May 24, 2016 12:08 PM, Matthieu Moy wrote:\n> >>> So, when trying a forbidden push, Git would deny it and the only way\n> >>> to force the push would be to remove the blacklist from the config,\nright?\n> >>>\n> >>> Probably the sanest way to go. I thought about adding a \"git push\n> >>> --force-even-if-in-blacklist\" or so, but I don't think the feature\n> >>> deserves one specific option (hence add some noise in `git push -h`).\n> >>\n> >> Yeah, I agree --even-if-in-blacklist is a road to madness, but I\n> >> wonder how this is different from setting pushURL to /dev/null or\n> >> something illegal and replace that phony configuration value when you\n> really need to push?\n> >\n> > May be missing the point, but isn't the original intent to provide\npolicy-\n> based to control the push destinations? A sufficiently knowledgeable\nperson,\n> being a couple of weeks into git, would easily see that the config points\nto a\n> black-listed destination and easily bypass it with a config update,\nrendering\n> all this pointless? This seems to me to be a lot of effort to go to for\nlimited\n> value - unless immutable attributes are going to be obtained from the\n> upstream repository - which also seems to run counter to the whole point.\n> \n> An actor with a bad intent will *always* be able to bypass this. However,\nI\n> see two use cases:\n> \n> (1) Accidental pushes.\n> An inexpierenced developer clones a repo from github.com, commits for\n> whatever reason company code and pushes. At this point the code leaked.\n> The blacklist feature could have warned/stopped the developer.\n> \n> (2) Intentional open source pushes.\n> At my day job we encourage people to contribute to open source. However,\n> we want them to follow our open source contribution process. If they run\n> \"git push\" on a new github.com repo then I want to interrupt the push and\n> tell them to look at our contribution guidelines. Afterwards they could\n> whitelist the repo on their local machine and push without trouble.\n> \n> In summary I think the feature could be a safety net for the developer to\nnot\n> leak company code.\n\nA more paranoid ;) and probably safer approach to satisfy UC.2 is to use\nsomething like Github Enterprise or Stash on a local server inside your\nfirewall as the place where developers are allowed to push code, and then\nfirewall block external entities. If you want to allow sharing of specific\nrepositories, set up a pull from the remote that is allowed through the\nfirewall and that server on a specific branch that can be shared (the branch\nshould obviously be secured by a person in a different role/function - or\nset up a Jenkins job to do the push, perhaps, from that server. This could\nbe considered potentially a closer implementation of your contribution\nprocess. For UC.1, if your clone is done via anonymous HTTPS, and push via\nSSH, accidents are less likely to happen, particularly if SSH to github is\nblocked at the firewall. I think there may be technical solutions to your\nproblem that do not involve modification to git. These are just suggestions\nfrom what I have observed others doing in harsher environments.\n\nCheers,\nRandall\n"},{"id":"287461","messageId":"20160524222451.GA23162@pug","threadId":"42399","inReplyTo":"vpq37p74nu1.fsf@anie.imag.fr","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Aaron Schrab","fromEmail":"aaron@schrab.com","sentAt":"2016-05-24T22:24:51Z","receivedAt":"2016-05-24T22:24:51Z","isPatch":false,"sender":{"key":"aaron@schrab.com","avatar":"https://avatars.githubusercontent.com/u/39620?v=4"},"body":"At 14:55 +0200 24 May 2016, Matthieu Moy wrote:\n>So, when trying a forbidden push, Git would deny it and the only way to\n>force the push would be to remove the blacklist from the config, right?\n>\n>Probably the sanest way to go. I thought about adding a \"git push\n>--force-even-if-in-blacklist\" or so, but I don't think the feature\n>deserves one specific option (hence add some noise in `git push -h`).\n\nIt might make sense to bypass the blacklist checking if the existing \n--no-verify is used. In the past I've used a pre-push hook to implement \na similar method of preventing accidental pushes, and found that to be a \ngood way to skip the checking when I wanted to override the check for a \nspecific push. The builtin blacklist checking could be seen as another \ntype of verification. The downside to that would be that if the \nblacklist was used along with a pre-push hook for different types of \nchecks users would likely only be able to see the error message from one \nof them; but that could also apply to a pre-push hook that implements \ndifferent types of checks and short circuits at the first failure.\n"},{"id":"287530","messageId":"20160525225214.GA2612@sigill.intra.peff.net","threadId":"42399","inReplyTo":"CAPc5daURo8SkbeGf0MEsp0sLzdzFfUOxptgusFr58UG9SKmDAA@mail.gmail.com","subject":"Re: [Opinion gathering] Git remote whitelist/blacklist","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-25T22:52:14Z","receivedAt":"2016-05-25T22:52:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 24, 2016 at 09:07:53AM -0700, Junio C Hamano wrote:\n\n> On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy\n> wrote:\n> > So, when trying a forbidden push, Git would deny it and the only way to\n> > force the push would be to remove the blacklist from the config, right?\n> >\n> > Probably the sanest way to go. I thought about adding a \"git push\n> > --force-even-if-in-blacklist\" or so, but I don't think the feature\n> > deserves one specific option (hence add some noise in `git push -h`).\n> \n> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder\n> how this is different from setting pushURL to /dev/null or something\n> illegal and replace that phony configuration value when you really need\n> to push?\n\nThat was my thought on reading this, too. In that scheme, you could do:\n\n git -c remote.foo.pushurl=example.com:repo.git push ...\n\nto override it. It would be nice if you could do:\n\n git -c remote.foo.pushurl= push ...\n\nto \"unset\" the push-url list and default to the regular fetch url, but\nthis is one of those multi-value config options that would have to learn\nthat explicitly.\n\nI suppose one can do:\n\n git -c remote.foo.pushurl=$(git config remote.foo.url)\n\nbut that is getting a bit long.\n\n-Peff\n"}]}