The 'svn' client can suffer an assertion failure during authentication to a server:
svn: subversion/libsvn_subr/dirent_uri.c:1050: svn_dirent_join_many: Assertion
`svn_dirent_is_canonical(base, pool)' failed.
if (at least) the following conditions are true:
* The value of $HOME [1] is non-canonical according to svn_dirent_is_canonical()
but resolves to a valid home directory according to typical interpretations.
For example, '/home/myname/' or '//home/myname/'.
* GPG-agent support is enabled in the 'password-stores' config option.
* The environment variable $GPG_AGENT_INFO is not set.
* Some conditions related to the sequence in which the Subversion client gets
authentication credentials. For example, it can be triggered after a correct
password is entered at a prompt, or if the correct username and password are
given on the command line and the authentication username is not equal to
the OS username.
The problem was seen and reported by a WANdisco customer running Subversion
1.8.11 and observing that this was a regression from 1.8.8. In this instance,
the value of $HOME had a trailing slash.
I found that the problem was introduced in Subversion 1.8.11, in the function
find_running_gpg_agent() which calls:
homedir = svn_user_get_homedir(pool);
... socket_name = svn_dirent_join_many(pool, homedir, ...);
The only previous caller of svn_user_get_homedir() canonicalizes the result
before passing it to svn_dirent_join_many(); this new code does not.
[1] If $HOME is not set, then Subversion would instead use the home directory
path reported by the operating system via APR. I have not confirmed whether that
could be non-canonical.
Bug
Major