git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [Opinion gathering] Git remote whitelist/blacklist

From
Lars Schneider <larsxschneider@gmail.com>
Date
May 24, 2016, 19:25 UTC
Message-ID
<166C4E9F-6231-47ED-88F3-EAD95DEE7DF2@gmail.com>
In-Reply-To
<002b01d1b5d7$aefd0a70$0cf71f50$@nexbridge.com>
Show 15 quoted lines
> 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

Previous: Junio C HamanoNext: Randall S. Becker
Message 10 of 15 in “[Opinion gathering] Git remote whitelist/blacklist”
  1. Francois BeutinMay 20, 2016
  2. Randall S. BeckerMay 20, 2016
  3. Francois BeutinMay 23, 2016
  4. Francois BeutinMay 24, 2016
  5. Lars SchneiderMay 24, 2016
  6. Matthieu MoyMay 24, 2016
  7. Junio C HamanoMay 24, 2016
  8. Randall S. BeckerMay 24, 2016
  9. Junio C HamanoMay 24, 2016
  10. Lars SchneiderMay 24, 2016
  11. Randall S. BeckerMay 24, 2016
  12. Lars SchneiderMay 24, 2016
  13. Matthieu MoyMay 24, 2016
  14. Jeff KingMay 25, 2016
  15. Aaron SchrabMay 24, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.