Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

Antoine Queru [off-list ref] 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

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

On 21 Jun 2016, at 08:20, Matthieu Moy [off-list ref] wrote:

Antoine Queru [off-list ref] writes:

quoted

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