Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.
- From
Lars Schneider <larsxschneider@gmail.com>
- Date
- Jun 21, 2016, 07:45 UTC
- Message-ID
- <827DA549-F046-4B52-90C2-ADB5BC72C16F@gmail.com>
- In-Reply-To
- <vpqfus7jc59.fsf@anie.imag.fr>
Show 25 quoted lines
> On 21 Jun 2016, at 08:20, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > > Antoine Queru <antoine.queru@ensimag.grenoble-inp.fr> writes: > >> However, in the last version, if we want to deny an website, >> including all schemes, we can blacklist the url without the >> scheme. For example, "pushBlacklist = github.com". By doing so, this >> remote is not an url anymore, and it can't be differenced with a local >> relative path. It's a problem because these two have a different >> treatement. The choice we made to solve this is to force the user to >> put the scheme "file://" before any local relative path. What do you >> think ? > > file:// URL can not be relative (well, you can invent a syntax where > they are, but that would be weird). > > I think you can just forbid relative path in whitelist/blacklist, hence > consider that anything that is neither a full URL nor an absolute path > is a protocol-less URL: > > * http://github.com = github.com with HTTP protocol > > * github.com = github.com with any protocol > > * /path/to/file or file:///path/to/file = local path
I agree. Ignoring relative paths (and mentioning that in the docs) sounds reasonable to me. I don't think that would be a limitation as I can't think of a white/blacklist use case for relative URLs.
Thanks, Lars