Re: [Opinion gathering] Git remote whitelist/blacklist

[Lars Schneider <larsxschneider@gmail.com>]

> On 24 May 2016, at 06:12, Francois Beutin <beutinf@ensimag.grenoble-inp.fr> 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