> On 24 May 2016, at 06:12, Francois Beutin <beutinf@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > >>>> On May 20, 2016 10:22 AM, Francois Beutin wrote: >>>> We (Ensimag students) plan to implement the "remote whitelist/blacklist" >>>> feature described in the SoC 2016 ideas, but first I would like to be >>>> sure >>>> we >>>> agree on what exactly this feature would be, and that the community sees >>>> an >>>> interest in it. >>>> >>>> The general idea is to add a way to prevent accidental push to the wrong >>>> repository, we see two ways to do it: >>>> First solution: >>>> - a whitelist: Git will accept a push to a repository in it >>>> - a blacklist: Git will refuse a push to a repository in it >>>> - a default policy >>>> >>>> Second solution: >>>> - a default policy >>>> - a list of repository not following the default policy >>>> >>>> The new options in config if we implement the first solution: >>>> >>>> [remote] >>>> # List of repository that will be allowed/denied with >>>> # a whitelist/blacklist >>>> whitelisted = "http://git-hosting.org"; >>>> blacklisted = "http://git-hosting2.org"; >>>> >>>> # What is displayed when the user attempts a push on an >>>> # unauthorised repository? (this option overwrites >>>> # the default message) >>>> denymessage = "message" >>>> >>>> # What git should do if the user attempts a push on an >>>> # unauthorised repository (reject or warn and >>>> # ask the user)? >>>> denypolicy = reject(default)/warning >>>> >>>> # How should unknown repositories be treated? >>>> defaultpolicy = allow(default)/deny >>>> >>>> >>>> Some concrete usage example: >>>> >>>> - A beginner is working on company code, to prevent him from >>>> accidentally pushing the code on a public repository, the >>>> company (or him) can do: >>>> git config --global remote.defaultpolicy "deny" >>>> git config --global remote.denymessage "Not the company's server!" >>>> git config --global remote.denypolicy "reject" >>>> git config --global remote.whitelisted "http://company-server.com"; >>>> >>>> >>>> - A regular git user fears that he might accidentally push sensible >>>> code to a public repository he often uses for free-time >>>> projects, he can do: >>>> git config remote.defaultpolicy "allow" #not really needed >>>> git config remote.denymessage "Are you sure it is the good server?" >>>> git config remote.denypolicy "warning" >>>> git config remote.blacklisted "http://github/personnalproject"; >>>> >>>> >>>> We would like to gather opinions about this before starting to >>>> implement it, is there any controversy? Do you prefer the >>>> first or second solution (or none)? Do you find the option's >>>> names accurate? >>> >>> How 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? >>> >>> Cheers, >>> Randall >>> >>> -- Brief whoami: NonStop&UNIX developer since approximately >>> UNIX(421664400)/NonStop(211288444200000000) >>> -- In my real life, I talk too much. >>> >> >> I agree that we cannot have a completly secure and reliable >> way to forbid a push to the wrong remote. This is not what >> our feature is trying to do, we assume that if a programmer >> tweaks his config file and changes the rules he knows what >> he is doing and we won't try to prevent it. >> Our goal is to implement a safeguard against accidental push, >> the feature will work only if the programmer wants it to. > > > In the end we decided to implement the first solution described > above. > We chose this version because we think there could have been > conflicts between the global and local config files. Moreover, we > think using two different lists for denied/allowed remotes is more > intuitive and user-friendly, and it will allow the user to use > "advanced" options such as: > denied = "http://git-hosting.org"; > allowed = "http://git-hosting.org/exception-repo"; > to deny a push to git-hosting.org EXCEPT to git-hosting.org/ > exception-repo > > We are unsure about the behavior to adopt in case of a conflicting > config file (for example a remote is in both the allowed and the > denied lists). The programm would print a warning message and: > - follow the defaultpolicy > OR - ask for confirmation > OR - reject the push > As of now we are inclined to implement the "ask for confirmation" > option. First of all: thanks for picking up the idea and working on the feature! I proposed the idea for GSoC and I am glad you CC'ed me because otherwise I would have missed that you are working on it :-) As you already stated correctly to Randall: this "protection" can never be completely secure as you can always override Git config settings. It is more a "hint" to protect inexperienced Git users. Therefore I would make the default as conservative as possible. To answer your question, I would reject the push (because the remote is in the denied list) and print a warning to point out the conflicting configs to the user. Cheers, Lars -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html