Re: [Opinion gathering] Git remote whitelist/blacklist

[Francois Beutin <beutinf@ensimag.grenoble-inp.fr>]

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.

----- Mail original -----
> De: "Randall S. Becker" <rsbecker@nexbridge.com>
> À: "Francois Beutin" <beutinf@ensimag.grenoble-inp.fr>, git@vger.kernel.org
> Cc: "matthieu moy" <matthieu.moy@grenoble-inp.fr>, "simon rabourg" <simon.rabourg@ensimag.grenoble-inp.fr>, "wiliam
> duclot" <wiliam.duclot@ensimag.grenoble-inp.fr>, "antoine queru" <antoine.queru@ensimag.grenoble-inp.fr>
> Envoyé: Vendredi 20 Mai 2016 16:22:17
> Objet: RE: [Opinion gathering] Git remote whitelist/blacklist
> 
> 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.
> 
> 
> 
>