git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Lars Schneider <larsxschneider@gmail.com>
To: "Randall S. Becker" <rsbecker@nexbridge.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Francois Beutin <beutinf@ensimag.grenoble-inp.fr>,
	Git Mailing List <git@vger.kernel.org>,
	simon rabourg <simon.rabourg@ensimag.grenoble-inp.fr>,
	wiliam duclot <wiliam.duclot@ensimag.grenoble-inp.fr>,
	antoine queru <antoine.queru@ensimag.grenoble-inp.fr>
Subject: Re: [Opinion gathering] Git remote whitelist/blacklist
Date: Tue, 24 May 2016 15:25:12 -0400	[thread overview]
Message-ID: <166C4E9F-6231-47ED-88F3-EAD95DEE7DF2@gmail.com> (raw)
In-Reply-To: <002b01d1b5d7$aefd0a70$0cf71f50$@nexbridge.com>


> 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

  parent reply	other threads:[~2016-05-24 19:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1040142021.5607762.1463753271105.JavaMail.zimbra@ensimag.grenoble-inp.fr>
2016-05-20 14:21 ` [Opinion gathering] Git remote whitelist/blacklist Francois Beutin
2016-05-20 14:22   ` Randall S. Becker
2016-05-23 12:51     ` Francois Beutin
2016-05-24 10:12       ` Francois Beutin
2016-05-24 10:55         ` Lars Schneider
2016-05-24 12:55           ` Matthieu Moy
2016-05-24 16:07             ` Junio C Hamano
2016-05-24 16:16               ` Randall S. Becker
2016-05-24 16:20                 ` Junio C Hamano
2016-05-24 19:25                 ` Lars Schneider [this message]
2016-05-24 21:02                   ` Randall S. Becker
2016-05-24 19:11               ` Lars Schneider
2016-05-24 19:22               ` Matthieu Moy
2016-05-25 22:52               ` Jeff King
2016-05-24 22:24             ` Aaron Schrab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=166C4E9F-6231-47ED-88F3-EAD95DEE7DF2@gmail.com \
    --to=larsxschneider@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=antoine.queru@ensimag.grenoble-inp.fr \
    --cc=beutinf@ensimag.grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=rsbecker@nexbridge.com \
    --cc=simon.rabourg@ensimag.grenoble-inp.fr \
    --cc=wiliam.duclot@ensimag.grenoble-inp.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).