You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2014/06/28 15:23:40 UTC
'svn auth' treats patterns as paths
'svn auth' URL-escapes and path-canonicalizes the pattern, which breaks some
use-cases. For example,
[[[
% $svn auth "<https://svn.apache.org:443> ASF Committers"
DBG: Pattern 0 is '%3chttps://svn.apache.org:443%3e%20asf%20committers' # [1]
% $svn auth "://svn.apache.org"
DBG: Pattern 0 is ':/svn.apache.org'
]]]
(The debug print is of b.patterns in svn_cl__auth().)
That's due to using svn_cl__args_to_target_array_print_reserved() to collect
patterns from argv. I see no reason to do canonicalization or escaping here,
or to forbid ".svn" and "_svn"; the arguments are not paths, they are patterns.
Removing slashes and adding %-escaping causes false negative matches.
(Removing the canonicalization will permit patterns such as '*///*', which will
never match, but that is not a problem: having zero matches is not an error.)
Seems to me we should just take the patterns from argv as-are, with no changes
save for transcoding (C encoding -> UTF-8).
Daniel
[1] As an aside, why did it downcase "ASF Committers"? Did svn think those
words were part of the hostname? I'm on Linux, on a case-sensitive filesystem.
Re: 'svn auth' treats patterns as paths
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Thu, Jul 03, 2014 at 13:51:49 +0100:
> I'll mention a few more suggestions about improvimg the 'svn auth' UI.
>
> Daniel Shahaf wrote on 28 June:
>
> > 'svn auth' URL-escapes and path-canonicalizes the pattern, which breaks some
> > use-cases.
> [...]
> > % $svn auth "<https://svn.apache.org:443> ASF Committers"
> > DBG: Pattern 0 is '%3chttps://svn.apache.org:443%3e%20asf%20committers'
> [...]
> > That's due to using svn_cl__args_to_target_array_print_reserved() [...]
> >
> > Seems to me we should just take the patterns from argv as-are, with no changes
> > save for transcoding (C encoding -> UTF-8).
>
> +1. Makes sense to me, at least as an initial step. If we want a more
> controlled way to search for (part of) a URL without regard to
> canonicalization differences, then that's something we could add, but
> not by blindly treating a general pattern as a URL.
>
Okay, filed http://subversion.tigris.org/issues/show_bug.cgi?id=4513
> > [1] As an aside, why did it downcase "ASF Committers"? Did svn think those
> > words were part of the hostname? I'm on Linux, on a case-sensitive filesystem.
>
> (I guess the URI parser treated "443> ASF Committers" as the port specifier. Why that should be down-cased I don't know.)
>
> Some more comments and suggestions.
>
> Suggestions: Rather than an implicit OR or AND relationship, specify patters using the '--search' and '--search-and' options that are used with 'svn log'. The kind of search available is then that an entry matches:
>
> (P1 and P2 [and ...]) or (Q1 and Q2 [and ...]) [or ...]
>
> The corresponding arguments would be:
>
> --search P1 --search-and P2 --search Q1 --search-and Q2
>
> Since we already have this UI syntax for 'svn log' it would seem sensible to re-use it.
>
I wonder if it would be a good idea to have a lispish expression parser
there? as in
--search-lisp "('or ('and P1 P2) ('and Q1 Q2))"
> The no-arguments form of the command currently means "list everything
> in the auth cache". For me this produces several pages of not very
> interesting output. Many of the entries look like these:
>
> ------------------------------------------------------------------------
> Credential kind: svn.simple
> Authentication realm: <http://127.0.0.1:6244> Slave Sync Repository
> Username: svnsync
>
> ------------------------------------------------------------------------
> Credential kind: svn.simple
> Authentication realm: <http://127.0.0.1:32340> Slave Sync Repository
> Username: svnsync
>
> ------------------------------------------------------------------------
> Credential kind: svn.simple
> Authentication realm: <http://127.0.0.2:9296> Subversion Repository
> Username: svnsync
>
> ------------------------------------------------------------------------
> Credential kind: svn.username
> Authentication realm: 0ae92485-7cf5-409c-8bf0-b23409813abc
> Username: jfoad
>
> ------------------------------------------------------------------------
> Credential kind: svn.username
> Authentication realm: a234dbc8-65dd-4788-820c-3291b73290db
> Username: username
>
> ------------------------------------------------------------------------
> Credential kind: svn.username
> Authentication realm: 5a9b881f-6758-4d55-8b19-09f827546be1
> Username:
>
> ------------------------------------------------------------------------
>
> Sure, it's information that is sometimes useful, but do we really want
> to reserve the no-arguments command for that? I suggest not. I think
> it would be better if one had to specify something like "--search=*"
> or "--list" or "--all" to get a full list.
>
> There are many things one might like to use 'svn auth' command for. We
> might want to use the no-arguments form, later, to mean something like
> "show me the authentication in use for the Subversion WC in the
> current working directory" or "re-authenticate to the repository in
> the current working directory".
>
I'm not sure whether your output is representative or an artifact of you
being an svn developer, but in any case, making 'svn auth' with no
arguments an error --- for now, so that we can assign it a meaning later
--- would get my vote.
> Finally, I'm wondering if "svn authn" as I fear "svn auth" will be
> confused with "authz" and with "author".
>
Poll users@ ?
Daniel
> - Julian
>
Re: 'svn auth' treats patterns as paths
Posted by Julian Foad <ju...@btopenworld.com>.
I'll mention a few more suggestions about improvimg the 'svn auth' UI.
Daniel Shahaf wrote on 28 June:
> 'svn auth' URL-escapes and path-canonicalizes the pattern, which breaks some
> use-cases.
[...]
> % $svn auth "<https://svn.apache.org:443> ASF Committers"
> DBG: Pattern 0 is '%3chttps://svn.apache.org:443%3e%20asf%20committers'
[...]
> That's due to using svn_cl__args_to_target_array_print_reserved() [...]
>
> Seems to me we should just take the patterns from argv as-are, with no changes
> save for transcoding (C encoding -> UTF-8).
+1. Makes sense to me, at least as an initial step. If we want a more controlled way to search for (part of) a URL without regard to canonicalization differences, then that's something we could add, but not by blindly treating a general pattern as a URL.
> [1] As an aside, why did it downcase "ASF Committers"? Did svn think those
> words were part of the hostname? I'm on Linux, on a case-sensitive filesystem.
(I guess the URI parser treated "443> ASF Committers" as the port specifier. Why that should be down-cased I don't know.)
Some more comments and suggestions.
The help says:
[[[
auth: Manage cached authentication credentials.
usage: 1. svn auth [PATTERN ...]
usage: 2. svn auth --remove PATTERN [PATTERN ...]
With no arguments, list all cached authentication credentials.
Authentication credentials include usernames, passwords,
SSL certificates, and SSL client-certificate passphrases.
If PATTERN is specified, only list credentials with attributes matching one
or more patterns. With the --remove option, remove cached authentication
credentials matching one or more patterns.
If more than one pattern is specified credentials are considered only they
match all specified patterns. Patterns are matched case-sensitively and may
contain glob wildcards: [...]
]]]
These two sentences in the help are inconsistent:
"If PATTERN is specified, only list credentials with attributes matching one
or more patterns."
"If more than one pattern is specified credentials are considered only they
match all specified patterns."
(And there's a missing "if" in that last sentence.)
Suggestions: Rather than an implicit OR or AND relationship, specify patters using the '--search' and '--search-and' options that are used with 'svn log'. The kind of search available is then that an entry matches:
(P1 and P2 [and ...]) or (Q1 and Q2 [and ...]) [or ...]
The corresponding arguments would be:
--search P1 --search-and P2 --search Q1 --search-and Q2
Since we already have this UI syntax for 'svn log' it would seem sensible to re-use it.
The no-arguments form of the command currently means "list everything in the auth cache". For me this produces several pages of not very interesting output. Many of the entries look like these:
------------------------------------------------------------------------
Credential kind: svn.simple
Authentication realm: <http://127.0.0.1:6244> Slave Sync Repository
Username: svnsync
------------------------------------------------------------------------
Credential kind: svn.simple
Authentication realm: <http://127.0.0.1:32340> Slave Sync Repository
Username: svnsync
------------------------------------------------------------------------
Credential kind: svn.simple
Authentication realm: <http://127.0.0.2:9296> Subversion Repository
Username: svnsync
------------------------------------------------------------------------
Credential kind: svn.username
Authentication realm: 0ae92485-7cf5-409c-8bf0-b23409813abc
Username: jfoad
------------------------------------------------------------------------
Credential kind: svn.username
Authentication realm: a234dbc8-65dd-4788-820c-3291b73290db
Username: username
------------------------------------------------------------------------
Credential kind: svn.username
Authentication realm: 5a9b881f-6758-4d55-8b19-09f827546be1
Username:
------------------------------------------------------------------------
Sure, it's information that is sometimes useful, but do we really want to reserve the no-arguments command for that? I suggest not. I think it would be better if one had to specify something like "--search=*" or "--list" or "--all" to get a full list.
There are many things one might like to use 'svn auth' command for. We might want to use the no-arguments form, later, to mean something like "show me the authentication in use for the Subversion WC in the current working directory" or "re-authenticate to the repository in the current working directory".
Finally, I'm wondering if "svn authn" as I fear "svn auth" will be confused with "authz" and with "author".
- Julian