[Opinion gathering] Git remote whitelist/blacklist

[Opinion gathering] Git remote whitelist/blacklist

[Francois Beutin]

Hi everyone,

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?

RE: [Opinion gathering] Git remote whitelist/blacklist

[Randall S. Becker]

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.

Re: [Opinion gathering] Git remote whitelist/blacklist

[Francois Beutin]

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.
> 
> 
> 
> 

Re: [Opinion gathering] Git remote whitelist/blacklist

[Francois Beutin]

> > > 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.

Re: [Opinion gathering] Git remote whitelist/blacklist

[Lars Schneider]

> 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

Re: [Opinion gathering] Git remote whitelist/blacklist

[Matthieu Moy]

Lars Schneider <larsxschneider@gmail.com> writes:

> 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.

So, when trying a forbidden push, Git would deny it and the only way to
force the push would be to remove the blacklist from the config, right?

Probably the sanest way to go. I thought about adding a "git push
--force-even-if-in-blacklist" or so, but I don't think the feature
deserves one specific option (hence add some noise in `git push -h`).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [Opinion gathering] Git remote whitelist/blacklist

[Junio C Hamano]

On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> So, when trying a forbidden push, Git would deny it and the only way to
> force the push would be to remove the blacklist from the config, right?
>
> Probably the sanest way to go. I thought about adding a "git push
> --force-even-if-in-blacklist" or so, but I don't think the feature
> deserves one specific option (hence add some noise in `git push -h`).

Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder
how this is different from setting pushURL to /dev/null or something
illegal and replace that phony configuration value when you really need
to push?

RE: [Opinion gathering] Git remote whitelist/blacklist

[Randall S. Becker]

On May 24, 2016 12:08 PM, Matthieu Moy wrote:
> > So, when trying a forbidden push, Git would deny it and the only way
> > to force the push would be to remove the blacklist from the config, right?
> >
> > Probably the sanest way to go. I thought about adding a "git push
> > --force-even-if-in-blacklist" or so, but I don't think the feature
> > deserves one specific option (hence add some noise in `git push -h`).
> 
> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder how
> this is different from setting pushURL to /dev/null or something illegal and
> replace that phony configuration value when you really need to push?

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.

Confusededly,
Randall

Re: [Opinion gathering] Git remote whitelist/blacklist

[Junio C Hamano]

On Tue, May 24, 2016 at 9:16 AM, Randall S. Becker
<rsbecker@nexbridge.com> wrote:
> May be missing the point, but isn't the original intent to provide policy-based to control the push

I didn't get the impression that those who are proposing were
interested in a "policy that you have to obey" at all. Isn't this more
about "I often by mistake say 'git push foo' which I want to prevent"?
At least that was the impression I was getting.

Re: [Opinion gathering] Git remote whitelist/blacklist

[Lars Schneider]

> On 24 May 2016, at 12:16, Randall S. Becker <rsbecker@nexbridge.com> wrote:
> 
> On May 24, 2016 12:08 PM, Matthieu Moy wrote:
>>> So, when trying a forbidden push, Git would deny it and the only way
>>> to force the push would be to remove the blacklist from the config, right?
>>> 
>>> Probably the sanest way to go. I thought about adding a "git push
>>> --force-even-if-in-blacklist" or so, but I don't think the feature
>>> deserves one specific option (hence add some noise in `git push -h`).
>> 
>> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder how
>> this is different from setting pushURL to /dev/null or something illegal and
>> replace that phony configuration value when you really need to push?
> 
> 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.

An actor with a bad intent will *always* be able to bypass this. However, I see two use cases:

(1) Accidental pushes. 
An 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.

(2) Intentional open source pushes.
At 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.

In summary I think the feature could be a safety net for the developer to not leak company code.

Cheers,
Lars

RE: [Opinion gathering] Git remote whitelist/blacklist

[Randall S. Becker]

On May 24, 2016 3:25 PM Lars Schneider wrote:
> > On 24 May 2016, at 12:16, Randall S. Becker <rsbecker@nexbridge.com>
> wrote:
> >
> > On May 24, 2016 12:08 PM, Matthieu Moy wrote:
> >>> So, when trying a forbidden push, Git would deny it and the only way
> >>> to force the push would be to remove the blacklist from the config,
right?
> >>>
> >>> Probably the sanest way to go. I thought about adding a "git push
> >>> --force-even-if-in-blacklist" or so, but I don't think the feature
> >>> deserves one specific option (hence add some noise in `git push -h`).
> >>
> >> Yeah, I agree --even-if-in-blacklist is a road to madness, but I
> >> wonder how this is different from setting pushURL to /dev/null or
> >> something illegal and replace that phony configuration value when you
> really need to push?
> >
> > 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.
> 
> An actor with a bad intent will *always* be able to bypass this. However,
I
> see two use cases:
> 
> (1) Accidental pushes.
> An 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.
> 
> (2) Intentional open source pushes.
> At 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.
> 
> In summary I think the feature could be a safety net for the developer to
not
> leak company code.

A more paranoid ;) and probably safer approach to satisfy UC.2 is to use
something like Github Enterprise or Stash on a local server inside your
firewall as the place where developers are allowed to push code, and then
firewall block external entities. If you want to allow sharing of specific
repositories, set up a pull from the remote that is allowed through the
firewall and that server on a specific branch that can be shared (the branch
should obviously be secured by a person in a different role/function - or
set up a Jenkins job to do the push, perhaps, from that server. This could
be considered potentially a closer implementation of your contribution
process. For UC.1, if your clone is done via anonymous HTTPS, and push via
SSH, accidents are less likely to happen, particularly if SSH to github is
blocked at the firewall. I think there may be technical solutions to your
problem that do not involve modification to git. These are just suggestions
from what I have observed others doing in harsher environments.

Cheers,
Randall

Re: [Opinion gathering] Git remote whitelist/blacklist

[Lars Schneider]

> On 24 May 2016, at 12:07, Junio C Hamano <gitster@pobox.com> wrote:
> 
> On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> So, when trying a forbidden push, Git would deny it and the only way to
>> force the push would be to remove the blacklist from the config, right?
>> 
>> Probably the sanest way to go. I thought about adding a "git push
>> --force-even-if-in-blacklist" or so, but I don't think the feature
>> deserves one specific option (hence add some noise in `git push -h`).
> 
> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder
> how this is different from setting pushURL to /dev/null or something
> illegal and replace that phony configuration value when you really need
> to push?
It is no different from changing the push URL. As a matter of fact, that
is how I've implemented this "blacklist" feature with the current version
of Git:
https://speakerdeck.com/larsxschneider/git-at-scale?slide=35

- Lars

Re: [Opinion gathering] Git remote whitelist/blacklist

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> So, when trying a forbidden push, Git would deny it and the only way to
>> force the push would be to remove the blacklist from the config, right?
>>
>> Probably the sanest way to go. I thought about adding a "git push
>> --force-even-if-in-blacklist" or so, but I don't think the feature
>> deserves one specific option (hence add some noise in `git push -h`).
>
> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder
> how this is different from setting pushURL to /dev/null or something
> illegal and replace that phony configuration value when you really need
> to push?

Changing pushURL is something you can do per-repo, but the
whitelist/blacklist could be done user-wide or even system-wide
(typically, if the sysadmin has control on everybody's /etc/gitconfig,
there can be a default policy to prevent accidental push to some URLs).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [Opinion gathering] Git remote whitelist/blacklist

[Jeff King]

On Tue, May 24, 2016 at 09:07:53AM -0700, Junio C Hamano wrote:

> On Tue, May 24, 2016 at 5:55 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
> > So, when trying a forbidden push, Git would deny it and the only way to
> > force the push would be to remove the blacklist from the config, right?
> >
> > Probably the sanest way to go. I thought about adding a "git push
> > --force-even-if-in-blacklist" or so, but I don't think the feature
> > deserves one specific option (hence add some noise in `git push -h`).
> 
> Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder
> how this is different from setting pushURL to /dev/null or something
> illegal and replace that phony configuration value when you really need
> to push?

That was my thought on reading this, too. In that scheme, you could do:

  git -c remote.foo.pushurl=example.com:repo.git push ...

to override it.  It would be nice if you could do:

  git -c remote.foo.pushurl= push ...

to "unset" the push-url list and default to the regular fetch url, but
this is one of those multi-value config options that would have to learn
that explicitly.

I suppose one can do:

  git -c remote.foo.pushurl=$(git config remote.foo.url)

but that is getting a bit long.

-Peff

Re: [Opinion gathering] Git remote whitelist/blacklist

[Aaron Schrab]

At 14:55 +0200 24 May 2016, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>So, when trying a forbidden push, Git would deny it and the only way to
>force the push would be to remove the blacklist from the config, right?
>
>Probably the sanest way to go. I thought about adding a "git push
>--force-even-if-in-blacklist" or so, but I don't think the feature
>deserves one specific option (hence add some noise in `git push -h`).

It might make sense to bypass the blacklist checking if the existing 
--no-verify is used.  In the past I've used a pre-push hook to implement 
a similar method of preventing accidental pushes, and found that to be a 
good way to skip the checking when I wanted to override the check for a 
specific push.  The builtin blacklist checking could be seen as another 
type of verification.  The downside to that would be that if the 
blacklist was used along with a pre-push hook for different types of 
checks users would likely only be able to see the error message from one 
of them; but that could also apply to a pre-push hook that implements 
different types of checks and short circuits at the first failure.