You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Guido Wischrop <Gu...@mgm-tp.com> on 2014/04/01 16:47:08 UTC
svn: E170000: 'https://user:pass@x' isn't in the same repository
as 'https://user:XXXXXXXX@x'
Hello,
I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this:
svn checkout https://user:pass@server/svn/p1/trunk
I get the following error immediately:
svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
X64) with the same result.
With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
works as expected. Is the user:pass@server scheme no longer supported?
I know, that I could use the --user --password parameters, but for some
reasons I won't.
Thanks,
Guido
PS: I'm not subscribed to the list, please cc me.
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository
as 'https://user:XXXXXXXX@x'
Posted by Guido Wischrop <Gu...@mgm-tp.com>.
On 08.04.2014 13:30, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>> Sent: dinsdag 8 april 2014 12:19
>> To: users@subversion.apache.org; dev@subversion.apache.org
>> Cc: Bert Huijben
>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
> repository
>> as 'https://user:XXXXXXXX@x'
>>
>>
>> On 04.04.2014 17:40, Bert Huijben wrote:
>>>> -----Original Message-----
>>>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>>>> Sent: vrijdag 4 april 2014 15:07
>>>> To: users@subversion.apache.org; dev@subversion.apache.org
>>>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
>>> repository
>>>> as 'https://user:XXXXXXXX@x'
>>>>
>>>>
>>>> On 03.04.2014 12:47, Philip Martin wrote:
>>>>> Guido Wischrop <Gu...@mgm-tp.com> writes:
>>>>>
>>>>>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
>>> this:
>>>>>> svn checkout https://user:pass@server/svn/p1/trunk
>>>>>>
>>>>>> I get the following error immediately:
>>>>>>
>>>>>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the
>> same
>>>>>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>>>>>>
>>>>>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
>>>>>> X64) with the same result.
>>>>>>
>>>>>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
>>>>>> works as expected. Is the user:pass@server scheme no longer
>>>> supported?
>>>>> I get the same problem with trunk on Linux. I can fix it with this
>>>>> patch but I'm not sure I understand all the consequences. Is there
> any
>>>>> reason we should be hiding the password here?
>>>>>
>>>>> Index: subversion/libsvn_ra_serf/options.c
>>>>>
>> ==========================================================
>>>> =========
>>>>> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
>>>>> +++ subversion/libsvn_ra_serf/options.c (working copy)
>>>>> @@ -245,7 +245,8 @@
>>>>> (char *)svn_fspath__canonicalize(val, session->pool);
>>>>> session->repos_root_str =
>>>>> svn_urlpath__canonicalize(
>>>>> - apr_uri_unparse(session->pool, &session->repos_root,
>>> 0),
>>>>> + apr_uri_unparse(session->pool, &session->repos_root,
>>>>> + APR_URI_UNP_REVEALPASSWORD),
>>>>> session->pool);
>>>>> }
>>>>> else if (svn_cstring_casecmp(key,
>> SVN_DAV_ME_RESOURCE_HEADER)
>>>> == 0)
>>>> So is this considered to be a bug? Is there another workaround as using
>>>> --user --password?
>>> As far as I can tell we only really support a username in the url for
>>> svn+XXX:// urls. In some other cases we just passed 'the unsupported'
> url
>> to
>>> the lower layers and the neon library (our <= 1.7 default) completely
>>> ignored this, while serf (which we use as default since 1.8) tried to
> use it
>>> as the hostname.
>>>
>>> I would really recommend not using a username in the url this way... You
>>> just store the password unencrypted on your disk in a place where it
> isn't
>>> even really used.
>>>
>>> It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
>>> different authentication id.
>>>
>>> And as Subversion doesn't actually use the username and password from
>> the
>>> url, they won't be updated if you ever want to change your password (or
>> use
>>> the working copy as a different user)
>>>
>>> Bert
>> We are using a apache reverse proxy in front of subversion. This apache
>> uses a Single Sign On module, which handles the authentication. So I
>> agree, that Subversion doesn't actually needs/uses the username and
>> password. Unfortunately I have no idea, how to remove the username and
>> password, as it seems not to be part of the ProxyPass directive.
>>
>> Is there any way to restore the previous behavior (ignore username and
>> password) in Subversion?
> I'm not sure what you are talking about here.
>
> Whether or not you are using some kind of proxy doesn't matter at all, as
> Subversion never passed the information to a server and never should start
> doing that as it would introduce an inconsistency.
>
> And the problem you describe is pure client side... the problem is caused by
> invoking commands on the clients with a username (and potentially a
> password) in the url.
>
>
> I really hope that your proxy server isn't able to just invoke commands on
> the individual client pc's as that would be a huge security problem in your
> setup.
>
>
> Our server protocol is completely described as relative to (and below) the
> BASE url of the repository, so we don't even process the hostname there.
>
> Some webbrowsers allowed passing user@ in their urls years ago and stopped
> for very good (security) reasons. We never supported this on urls except for
> the very specific svn+ssh://user@hostname/ cases where there is no other way
> to pass a user (and you might actually use a different user for the SSH part
> and the svnserve connection that we tunnel over it).
>
>
> The problem is that we accidentally accepted and ignored these parts in our
> URLs (because the libneon parse functions ignored it for us) and somehow
> your code started relying on that.
>
>
> As we rely on the repository root url being canonical, you are introducing
> problems for yourself by adding details there that will make working copies
> incompatible with clients that don't expect this.
>
> E.g.
> $ svn cp WC1/file WC2/file
>
> Will never work if WC1 and WC2 are from different repositories... and the
> way we check that is by comparing the repository root url and the UUID. If
> either is different you will get errors that the repository is not the same.
>
>
>
> The best thing I can think of is that we automatically redirect DAV
> repositories with a username in their url to the location without the
> username (as that would resolve the problem I just described for almost
> every user that accidentally uses this), but I'm guessing that this will
> break your use case even further.
>
>
> Bert
Thank you very much for that detailed explanation. Now I think we just
have to live the new behavior and fix our scripts accordingly.
Thanks again,
Guido
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository
as 'https://user:XXXXXXXX@x'
Posted by Guido Wischrop <Gu...@mgm-tp.com>.
On 08.04.2014 13:30, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>> Sent: dinsdag 8 april 2014 12:19
>> To: users@subversion.apache.org; dev@subversion.apache.org
>> Cc: Bert Huijben
>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
> repository
>> as 'https://user:XXXXXXXX@x'
>>
>>
>> On 04.04.2014 17:40, Bert Huijben wrote:
>>>> -----Original Message-----
>>>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>>>> Sent: vrijdag 4 april 2014 15:07
>>>> To: users@subversion.apache.org; dev@subversion.apache.org
>>>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
>>> repository
>>>> as 'https://user:XXXXXXXX@x'
>>>>
>>>>
>>>> On 03.04.2014 12:47, Philip Martin wrote:
>>>>> Guido Wischrop <Gu...@mgm-tp.com> writes:
>>>>>
>>>>>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
>>> this:
>>>>>> svn checkout https://user:pass@server/svn/p1/trunk
>>>>>>
>>>>>> I get the following error immediately:
>>>>>>
>>>>>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the
>> same
>>>>>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>>>>>>
>>>>>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
>>>>>> X64) with the same result.
>>>>>>
>>>>>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
>>>>>> works as expected. Is the user:pass@server scheme no longer
>>>> supported?
>>>>> I get the same problem with trunk on Linux. I can fix it with this
>>>>> patch but I'm not sure I understand all the consequences. Is there
> any
>>>>> reason we should be hiding the password here?
>>>>>
>>>>> Index: subversion/libsvn_ra_serf/options.c
>>>>>
>> ==========================================================
>>>> =========
>>>>> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
>>>>> +++ subversion/libsvn_ra_serf/options.c (working copy)
>>>>> @@ -245,7 +245,8 @@
>>>>> (char *)svn_fspath__canonicalize(val, session->pool);
>>>>> session->repos_root_str =
>>>>> svn_urlpath__canonicalize(
>>>>> - apr_uri_unparse(session->pool, &session->repos_root,
>>> 0),
>>>>> + apr_uri_unparse(session->pool, &session->repos_root,
>>>>> + APR_URI_UNP_REVEALPASSWORD),
>>>>> session->pool);
>>>>> }
>>>>> else if (svn_cstring_casecmp(key,
>> SVN_DAV_ME_RESOURCE_HEADER)
>>>> == 0)
>>>> So is this considered to be a bug? Is there another workaround as using
>>>> --user --password?
>>> As far as I can tell we only really support a username in the url for
>>> svn+XXX:// urls. In some other cases we just passed 'the unsupported'
> url
>> to
>>> the lower layers and the neon library (our <= 1.7 default) completely
>>> ignored this, while serf (which we use as default since 1.8) tried to
> use it
>>> as the hostname.
>>>
>>> I would really recommend not using a username in the url this way... You
>>> just store the password unencrypted on your disk in a place where it
> isn't
>>> even really used.
>>>
>>> It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
>>> different authentication id.
>>>
>>> And as Subversion doesn't actually use the username and password from
>> the
>>> url, they won't be updated if you ever want to change your password (or
>> use
>>> the working copy as a different user)
>>>
>>> Bert
>> We are using a apache reverse proxy in front of subversion. This apache
>> uses a Single Sign On module, which handles the authentication. So I
>> agree, that Subversion doesn't actually needs/uses the username and
>> password. Unfortunately I have no idea, how to remove the username and
>> password, as it seems not to be part of the ProxyPass directive.
>>
>> Is there any way to restore the previous behavior (ignore username and
>> password) in Subversion?
> I'm not sure what you are talking about here.
>
> Whether or not you are using some kind of proxy doesn't matter at all, as
> Subversion never passed the information to a server and never should start
> doing that as it would introduce an inconsistency.
>
> And the problem you describe is pure client side... the problem is caused by
> invoking commands on the clients with a username (and potentially a
> password) in the url.
>
>
> I really hope that your proxy server isn't able to just invoke commands on
> the individual client pc's as that would be a huge security problem in your
> setup.
>
>
> Our server protocol is completely described as relative to (and below) the
> BASE url of the repository, so we don't even process the hostname there.
>
> Some webbrowsers allowed passing user@ in their urls years ago and stopped
> for very good (security) reasons. We never supported this on urls except for
> the very specific svn+ssh://user@hostname/ cases where there is no other way
> to pass a user (and you might actually use a different user for the SSH part
> and the svnserve connection that we tunnel over it).
>
>
> The problem is that we accidentally accepted and ignored these parts in our
> URLs (because the libneon parse functions ignored it for us) and somehow
> your code started relying on that.
>
>
> As we rely on the repository root url being canonical, you are introducing
> problems for yourself by adding details there that will make working copies
> incompatible with clients that don't expect this.
>
> E.g.
> $ svn cp WC1/file WC2/file
>
> Will never work if WC1 and WC2 are from different repositories... and the
> way we check that is by comparing the repository root url and the UUID. If
> either is different you will get errors that the repository is not the same.
>
>
>
> The best thing I can think of is that we automatically redirect DAV
> repositories with a username in their url to the location without the
> username (as that would resolve the problem I just described for almost
> every user that accidentally uses this), but I'm guessing that this will
> break your use case even further.
>
>
> Bert
Thank you very much for that detailed explanation. Now I think we just
have to live the new behavior and fix our scripts accordingly.
Thanks again,
Guido
RE: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
> Sent: dinsdag 8 april 2014 12:19
> To: users@subversion.apache.org; dev@subversion.apache.org
> Cc: Bert Huijben
> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
repository
> as 'https://user:XXXXXXXX@x'
>
>
> On 04.04.2014 17:40, Bert Huijben wrote:
> >
> >> -----Original Message-----
> >> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
> >> Sent: vrijdag 4 april 2014 15:07
> >> To: users@subversion.apache.org; dev@subversion.apache.org
> >> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
> > repository
> >> as 'https://user:XXXXXXXX@x'
> >>
> >>
> >> On 03.04.2014 12:47, Philip Martin wrote:
> >>> Guido Wischrop <Gu...@mgm-tp.com> writes:
> >>>
> >>>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
> > this:
> >>>> svn checkout https://user:pass@server/svn/p1/trunk
> >>>>
> >>>> I get the following error immediately:
> >>>>
> >>>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the
> same
> >>>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
> >>>>
> >>>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
> >>>> X64) with the same result.
> >>>>
> >>>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
> >>>> works as expected. Is the user:pass@server scheme no longer
> >> supported?
> >>> I get the same problem with trunk on Linux. I can fix it with this
> >>> patch but I'm not sure I understand all the consequences. Is there
any
> >>> reason we should be hiding the password here?
> >>>
> >>> Index: subversion/libsvn_ra_serf/options.c
> >>>
> >>
> ==========================================================
> >> =========
> >>> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
> >>> +++ subversion/libsvn_ra_serf/options.c (working copy)
> >>> @@ -245,7 +245,8 @@
> >>> (char *)svn_fspath__canonicalize(val, session->pool);
> >>> session->repos_root_str =
> >>> svn_urlpath__canonicalize(
> >>> - apr_uri_unparse(session->pool, &session->repos_root,
> > 0),
> >>> + apr_uri_unparse(session->pool, &session->repos_root,
> >>> + APR_URI_UNP_REVEALPASSWORD),
> >>> session->pool);
> >>> }
> >>> else if (svn_cstring_casecmp(key,
> SVN_DAV_ME_RESOURCE_HEADER)
> >> == 0)
> >>>
> >> So is this considered to be a bug? Is there another workaround as using
> >> --user --password?
> > As far as I can tell we only really support a username in the url for
> > svn+XXX:// urls. In some other cases we just passed 'the unsupported'
url
> to
> > the lower layers and the neon library (our <= 1.7 default) completely
> > ignored this, while serf (which we use as default since 1.8) tried to
use it
> > as the hostname.
> >
> > I would really recommend not using a username in the url this way... You
> > just store the password unencrypted on your disk in a place where it
isn't
> > even really used.
> >
> > It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
> > different authentication id.
> >
> > And as Subversion doesn't actually use the username and password from
> the
> > url, they won't be updated if you ever want to change your password (or
> use
> > the working copy as a different user)
> >
> > Bert
>
> We are using a apache reverse proxy in front of subversion. This apache
> uses a Single Sign On module, which handles the authentication. So I
> agree, that Subversion doesn't actually needs/uses the username and
> password. Unfortunately I have no idea, how to remove the username and
> password, as it seems not to be part of the ProxyPass directive.
>
> Is there any way to restore the previous behavior (ignore username and
> password) in Subversion?
I'm not sure what you are talking about here.
Whether or not you are using some kind of proxy doesn't matter at all, as
Subversion never passed the information to a server and never should start
doing that as it would introduce an inconsistency.
And the problem you describe is pure client side... the problem is caused by
invoking commands on the clients with a username (and potentially a
password) in the url.
I really hope that your proxy server isn't able to just invoke commands on
the individual client pc's as that would be a huge security problem in your
setup.
Our server protocol is completely described as relative to (and below) the
BASE url of the repository, so we don't even process the hostname there.
Some webbrowsers allowed passing user@ in their urls years ago and stopped
for very good (security) reasons. We never supported this on urls except for
the very specific svn+ssh://user@hostname/ cases where there is no other way
to pass a user (and you might actually use a different user for the SSH part
and the svnserve connection that we tunnel over it).
The problem is that we accidentally accepted and ignored these parts in our
URLs (because the libneon parse functions ignored it for us) and somehow
your code started relying on that.
As we rely on the repository root url being canonical, you are introducing
problems for yourself by adding details there that will make working copies
incompatible with clients that don't expect this.
E.g.
$ svn cp WC1/file WC2/file
Will never work if WC1 and WC2 are from different repositories... and the
way we check that is by comparing the repository root url and the UUID. If
either is different you will get errors that the repository is not the same.
The best thing I can think of is that we automatically redirect DAV
repositories with a username in their url to the location without the
username (as that would resolve the problem I just described for almost
every user that accidentally uses this), but I'm guessing that this will
break your use case even further.
Bert
>
> Thanks,
> Guido
RE: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
> Sent: dinsdag 8 april 2014 12:19
> To: users@subversion.apache.org; dev@subversion.apache.org
> Cc: Bert Huijben
> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
repository
> as 'https://user:XXXXXXXX@x'
>
>
> On 04.04.2014 17:40, Bert Huijben wrote:
> >
> >> -----Original Message-----
> >> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
> >> Sent: vrijdag 4 april 2014 15:07
> >> To: users@subversion.apache.org; dev@subversion.apache.org
> >> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
> > repository
> >> as 'https://user:XXXXXXXX@x'
> >>
> >>
> >> On 03.04.2014 12:47, Philip Martin wrote:
> >>> Guido Wischrop <Gu...@mgm-tp.com> writes:
> >>>
> >>>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
> > this:
> >>>> svn checkout https://user:pass@server/svn/p1/trunk
> >>>>
> >>>> I get the following error immediately:
> >>>>
> >>>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the
> same
> >>>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
> >>>>
> >>>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
> >>>> X64) with the same result.
> >>>>
> >>>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
> >>>> works as expected. Is the user:pass@server scheme no longer
> >> supported?
> >>> I get the same problem with trunk on Linux. I can fix it with this
> >>> patch but I'm not sure I understand all the consequences. Is there
any
> >>> reason we should be hiding the password here?
> >>>
> >>> Index: subversion/libsvn_ra_serf/options.c
> >>>
> >>
> ==========================================================
> >> =========
> >>> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
> >>> +++ subversion/libsvn_ra_serf/options.c (working copy)
> >>> @@ -245,7 +245,8 @@
> >>> (char *)svn_fspath__canonicalize(val, session->pool);
> >>> session->repos_root_str =
> >>> svn_urlpath__canonicalize(
> >>> - apr_uri_unparse(session->pool, &session->repos_root,
> > 0),
> >>> + apr_uri_unparse(session->pool, &session->repos_root,
> >>> + APR_URI_UNP_REVEALPASSWORD),
> >>> session->pool);
> >>> }
> >>> else if (svn_cstring_casecmp(key,
> SVN_DAV_ME_RESOURCE_HEADER)
> >> == 0)
> >>>
> >> So is this considered to be a bug? Is there another workaround as using
> >> --user --password?
> > As far as I can tell we only really support a username in the url for
> > svn+XXX:// urls. In some other cases we just passed 'the unsupported'
url
> to
> > the lower layers and the neon library (our <= 1.7 default) completely
> > ignored this, while serf (which we use as default since 1.8) tried to
use it
> > as the hostname.
> >
> > I would really recommend not using a username in the url this way... You
> > just store the password unencrypted on your disk in a place where it
isn't
> > even really used.
> >
> > It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
> > different authentication id.
> >
> > And as Subversion doesn't actually use the username and password from
> the
> > url, they won't be updated if you ever want to change your password (or
> use
> > the working copy as a different user)
> >
> > Bert
>
> We are using a apache reverse proxy in front of subversion. This apache
> uses a Single Sign On module, which handles the authentication. So I
> agree, that Subversion doesn't actually needs/uses the username and
> password. Unfortunately I have no idea, how to remove the username and
> password, as it seems not to be part of the ProxyPass directive.
>
> Is there any way to restore the previous behavior (ignore username and
> password) in Subversion?
I'm not sure what you are talking about here.
Whether or not you are using some kind of proxy doesn't matter at all, as
Subversion never passed the information to a server and never should start
doing that as it would introduce an inconsistency.
And the problem you describe is pure client side... the problem is caused by
invoking commands on the clients with a username (and potentially a
password) in the url.
I really hope that your proxy server isn't able to just invoke commands on
the individual client pc's as that would be a huge security problem in your
setup.
Our server protocol is completely described as relative to (and below) the
BASE url of the repository, so we don't even process the hostname there.
Some webbrowsers allowed passing user@ in their urls years ago and stopped
for very good (security) reasons. We never supported this on urls except for
the very specific svn+ssh://user@hostname/ cases where there is no other way
to pass a user (and you might actually use a different user for the SSH part
and the svnserve connection that we tunnel over it).
The problem is that we accidentally accepted and ignored these parts in our
URLs (because the libneon parse functions ignored it for us) and somehow
your code started relying on that.
As we rely on the repository root url being canonical, you are introducing
problems for yourself by adding details there that will make working copies
incompatible with clients that don't expect this.
E.g.
$ svn cp WC1/file WC2/file
Will never work if WC1 and WC2 are from different repositories... and the
way we check that is by comparing the repository root url and the UUID. If
either is different you will get errors that the repository is not the same.
The best thing I can think of is that we automatically redirect DAV
repositories with a username in their url to the location without the
username (as that would resolve the problem I just described for almost
every user that accidentally uses this), but I'm guessing that this will
break your use case even further.
Bert
>
> Thanks,
> Guido
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository
as 'https://user:XXXXXXXX@x'
Posted by Guido Wischrop <Gu...@mgm-tp.com>.
On 04.04.2014 17:40, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>> Sent: vrijdag 4 april 2014 15:07
>> To: users@subversion.apache.org; dev@subversion.apache.org
>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
> repository
>> as 'https://user:XXXXXXXX@x'
>>
>>
>> On 03.04.2014 12:47, Philip Martin wrote:
>>> Guido Wischrop <Gu...@mgm-tp.com> writes:
>>>
>>>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
> this:
>>>> svn checkout https://user:pass@server/svn/p1/trunk
>>>>
>>>> I get the following error immediately:
>>>>
>>>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
>>>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>>>>
>>>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
>>>> X64) with the same result.
>>>>
>>>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
>>>> works as expected. Is the user:pass@server scheme no longer
>> supported?
>>> I get the same problem with trunk on Linux. I can fix it with this
>>> patch but I'm not sure I understand all the consequences. Is there any
>>> reason we should be hiding the password here?
>>>
>>> Index: subversion/libsvn_ra_serf/options.c
>>>
>> ==========================================================
>> =========
>>> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
>>> +++ subversion/libsvn_ra_serf/options.c (working copy)
>>> @@ -245,7 +245,8 @@
>>> (char *)svn_fspath__canonicalize(val, session->pool);
>>> session->repos_root_str =
>>> svn_urlpath__canonicalize(
>>> - apr_uri_unparse(session->pool, &session->repos_root,
> 0),
>>> + apr_uri_unparse(session->pool, &session->repos_root,
>>> + APR_URI_UNP_REVEALPASSWORD),
>>> session->pool);
>>> }
>>> else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER)
>> == 0)
>>>
>> So is this considered to be a bug? Is there another workaround as using
>> --user --password?
> As far as I can tell we only really support a username in the url for
> svn+XXX:// urls. In some other cases we just passed 'the unsupported' url to
> the lower layers and the neon library (our <= 1.7 default) completely
> ignored this, while serf (which we use as default since 1.8) tried to use it
> as the hostname.
>
> I would really recommend not using a username in the url this way... You
> just store the password unencrypted on your disk in a place where it isn't
> even really used.
>
> It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
> different authentication id.
>
> And as Subversion doesn't actually use the username and password from the
> url, they won't be updated if you ever want to change your password (or use
> the working copy as a different user)
>
> Bert
We are using a apache reverse proxy in front of subversion. This apache
uses a Single Sign On module, which handles the authentication. So I
agree, that Subversion doesn't actually needs/uses the username and
password. Unfortunately I have no idea, how to remove the username and
password, as it seems not to be part of the ProxyPass directive.
Is there any way to restore the previous behavior (ignore username and
password) in Subversion?
Thanks,
Guido
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository
as 'https://user:XXXXXXXX@x'
Posted by Guido Wischrop <Gu...@mgm-tp.com>.
On 04.04.2014 17:40, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>> Sent: vrijdag 4 april 2014 15:07
>> To: users@subversion.apache.org; dev@subversion.apache.org
>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
> repository
>> as 'https://user:XXXXXXXX@x'
>>
>>
>> On 03.04.2014 12:47, Philip Martin wrote:
>>> Guido Wischrop <Gu...@mgm-tp.com> writes:
>>>
>>>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
> this:
>>>> svn checkout https://user:pass@server/svn/p1/trunk
>>>>
>>>> I get the following error immediately:
>>>>
>>>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
>>>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>>>>
>>>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
>>>> X64) with the same result.
>>>>
>>>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
>>>> works as expected. Is the user:pass@server scheme no longer
>> supported?
>>> I get the same problem with trunk on Linux. I can fix it with this
>>> patch but I'm not sure I understand all the consequences. Is there any
>>> reason we should be hiding the password here?
>>>
>>> Index: subversion/libsvn_ra_serf/options.c
>>>
>> ==========================================================
>> =========
>>> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
>>> +++ subversion/libsvn_ra_serf/options.c (working copy)
>>> @@ -245,7 +245,8 @@
>>> (char *)svn_fspath__canonicalize(val, session->pool);
>>> session->repos_root_str =
>>> svn_urlpath__canonicalize(
>>> - apr_uri_unparse(session->pool, &session->repos_root,
> 0),
>>> + apr_uri_unparse(session->pool, &session->repos_root,
>>> + APR_URI_UNP_REVEALPASSWORD),
>>> session->pool);
>>> }
>>> else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER)
>> == 0)
>>>
>> So is this considered to be a bug? Is there another workaround as using
>> --user --password?
> As far as I can tell we only really support a username in the url for
> svn+XXX:// urls. In some other cases we just passed 'the unsupported' url to
> the lower layers and the neon library (our <= 1.7 default) completely
> ignored this, while serf (which we use as default since 1.8) tried to use it
> as the hostname.
>
> I would really recommend not using a username in the url this way... You
> just store the password unencrypted on your disk in a place where it isn't
> even really used.
>
> It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
> different authentication id.
>
> And as Subversion doesn't actually use the username and password from the
> url, they won't be updated if you ever want to change your password (or use
> the working copy as a different user)
>
> Bert
We are using a apache reverse proxy in front of subversion. This apache
uses a Single Sign On module, which handles the authentication. So I
agree, that Subversion doesn't actually needs/uses the username and
password. Unfortunately I have no idea, how to remove the username and
password, as it seems not to be part of the ProxyPass directive.
Is there any way to restore the previous behavior (ignore username and
password) in Subversion?
Thanks,
Guido
RE: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
> Sent: vrijdag 4 april 2014 15:07
> To: users@subversion.apache.org; dev@subversion.apache.org
> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
repository
> as 'https://user:XXXXXXXX@x'
>
>
> On 03.04.2014 12:47, Philip Martin wrote:
> > Guido Wischrop <Gu...@mgm-tp.com> writes:
> >
> >> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
this:
> >>
> >> svn checkout https://user:pass@server/svn/p1/trunk
> >>
> >> I get the following error immediately:
> >>
> >> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
> >> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
> >>
> >> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
> >> X64) with the same result.
> >>
> >> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
> >> works as expected. Is the user:pass@server scheme no longer
> supported?
> > I get the same problem with trunk on Linux. I can fix it with this
> > patch but I'm not sure I understand all the consequences. Is there any
> > reason we should be hiding the password here?
> >
> > Index: subversion/libsvn_ra_serf/options.c
> >
> ==========================================================
> =========
> > --- subversion/libsvn_ra_serf/options.c (revision 1584323)
> > +++ subversion/libsvn_ra_serf/options.c (working copy)
> > @@ -245,7 +245,8 @@
> > (char *)svn_fspath__canonicalize(val, session->pool);
> > session->repos_root_str =
> > svn_urlpath__canonicalize(
> > - apr_uri_unparse(session->pool, &session->repos_root,
0),
> > + apr_uri_unparse(session->pool, &session->repos_root,
> > + APR_URI_UNP_REVEALPASSWORD),
> > session->pool);
> > }
> > else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER)
> == 0)
> >
> >
>
> So is this considered to be a bug? Is there another workaround as using
> --user --password?
As far as I can tell we only really support a username in the url for
svn+XXX:// urls. In some other cases we just passed 'the unsupported' url to
the lower layers and the neon library (our <= 1.7 default) completely
ignored this, while serf (which we use as default since 1.8) tried to use it
as the hostname.
I would really recommend not using a username in the url this way... You
just store the password unencrypted on your disk in a place where it isn't
even really used.
It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
different authentication id.
And as Subversion doesn't actually use the username and password from the
url, they won't be updated if you ever want to change your password (or use
the working copy as a different user)
Bert
>
> Thanks,
> Guido
RE: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
> Sent: vrijdag 4 april 2014 15:07
> To: users@subversion.apache.org; dev@subversion.apache.org
> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
repository
> as 'https://user:XXXXXXXX@x'
>
>
> On 03.04.2014 12:47, Philip Martin wrote:
> > Guido Wischrop <Gu...@mgm-tp.com> writes:
> >
> >> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
this:
> >>
> >> svn checkout https://user:pass@server/svn/p1/trunk
> >>
> >> I get the following error immediately:
> >>
> >> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
> >> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
> >>
> >> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
> >> X64) with the same result.
> >>
> >> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
> >> works as expected. Is the user:pass@server scheme no longer
> supported?
> > I get the same problem with trunk on Linux. I can fix it with this
> > patch but I'm not sure I understand all the consequences. Is there any
> > reason we should be hiding the password here?
> >
> > Index: subversion/libsvn_ra_serf/options.c
> >
> ==========================================================
> =========
> > --- subversion/libsvn_ra_serf/options.c (revision 1584323)
> > +++ subversion/libsvn_ra_serf/options.c (working copy)
> > @@ -245,7 +245,8 @@
> > (char *)svn_fspath__canonicalize(val, session->pool);
> > session->repos_root_str =
> > svn_urlpath__canonicalize(
> > - apr_uri_unparse(session->pool, &session->repos_root,
0),
> > + apr_uri_unparse(session->pool, &session->repos_root,
> > + APR_URI_UNP_REVEALPASSWORD),
> > session->pool);
> > }
> > else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER)
> == 0)
> >
> >
>
> So is this considered to be a bug? Is there another workaround as using
> --user --password?
As far as I can tell we only really support a username in the url for
svn+XXX:// urls. In some other cases we just passed 'the unsupported' url to
the lower layers and the neon library (our <= 1.7 default) completely
ignored this, while serf (which we use as default since 1.8) tried to use it
as the hostname.
I would really recommend not using a username in the url this way... You
just store the password unencrypted on your disk in a place where it isn't
even really used.
It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
different authentication id.
And as Subversion doesn't actually use the username and password from the
url, they won't be updated if you ever want to change your password (or use
the working copy as a different user)
Bert
>
> Thanks,
> Guido
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository
as 'https://user:XXXXXXXX@x'
Posted by Guido Wischrop <Gu...@mgm-tp.com>.
On 03.04.2014 12:47, Philip Martin wrote:
> Guido Wischrop <Gu...@mgm-tp.com> writes:
>
>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this:
>>
>> svn checkout https://user:pass@server/svn/p1/trunk
>>
>> I get the following error immediately:
>>
>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>>
>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
>> X64) with the same result.
>>
>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
>> works as expected. Is the user:pass@server scheme no longer supported?
> I get the same problem with trunk on Linux. I can fix it with this
> patch but I'm not sure I understand all the consequences. Is there any
> reason we should be hiding the password here?
>
> Index: subversion/libsvn_ra_serf/options.c
> ===================================================================
> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
> +++ subversion/libsvn_ra_serf/options.c (working copy)
> @@ -245,7 +245,8 @@
> (char *)svn_fspath__canonicalize(val, session->pool);
> session->repos_root_str =
> svn_urlpath__canonicalize(
> - apr_uri_unparse(session->pool, &session->repos_root, 0),
> + apr_uri_unparse(session->pool, &session->repos_root,
> + APR_URI_UNP_REVEALPASSWORD),
> session->pool);
> }
> else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) == 0)
>
>
So is this considered to be a bug? Is there another workaround as using
--user --password?
Thanks,
Guido
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository
as 'https://user:XXXXXXXX@x'
Posted by Guido Wischrop <Gu...@mgm-tp.com>.
On 03.04.2014 12:47, Philip Martin wrote:
> Guido Wischrop <Gu...@mgm-tp.com> writes:
>
>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this:
>>
>> svn checkout https://user:pass@server/svn/p1/trunk
>>
>> I get the following error immediately:
>>
>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>>
>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
>> X64) with the same result.
>>
>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
>> works as expected. Is the user:pass@server scheme no longer supported?
> I get the same problem with trunk on Linux. I can fix it with this
> patch but I'm not sure I understand all the consequences. Is there any
> reason we should be hiding the password here?
>
> Index: subversion/libsvn_ra_serf/options.c
> ===================================================================
> --- subversion/libsvn_ra_serf/options.c (revision 1584323)
> +++ subversion/libsvn_ra_serf/options.c (working copy)
> @@ -245,7 +245,8 @@
> (char *)svn_fspath__canonicalize(val, session->pool);
> session->repos_root_str =
> svn_urlpath__canonicalize(
> - apr_uri_unparse(session->pool, &session->repos_root, 0),
> + apr_uri_unparse(session->pool, &session->repos_root,
> + APR_URI_UNP_REVEALPASSWORD),
> session->pool);
> }
> else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) == 0)
>
>
So is this considered to be a bug? Is there another workaround as using
--user --password?
Thanks,
Guido
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
Posted by Philip Martin <ph...@wandisco.com>.
Guido Wischrop <Gu...@mgm-tp.com> writes:
> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this:
>
> svn checkout https://user:pass@server/svn/p1/trunk
>
> I get the following error immediately:
>
> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>
> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
> X64) with the same result.
>
> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
> works as expected. Is the user:pass@server scheme no longer supported?
I get the same problem with trunk on Linux. I can fix it with this
patch but I'm not sure I understand all the consequences. Is there any
reason we should be hiding the password here?
Index: subversion/libsvn_ra_serf/options.c
===================================================================
--- subversion/libsvn_ra_serf/options.c (revision 1584323)
+++ subversion/libsvn_ra_serf/options.c (working copy)
@@ -245,7 +245,8 @@
(char *)svn_fspath__canonicalize(val, session->pool);
session->repos_root_str =
svn_urlpath__canonicalize(
- apr_uri_unparse(session->pool, &session->repos_root, 0),
+ apr_uri_unparse(session->pool, &session->repos_root,
+ APR_URI_UNP_REVEALPASSWORD),
session->pool);
}
else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) == 0)
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
Posted by Philip Martin <ph...@wandisco.com>.
Guido Wischrop <Gu...@mgm-tp.com> writes:
> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this:
>
> svn checkout https://user:pass@server/svn/p1/trunk
>
> I get the following error immediately:
>
> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>
> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
> X64) with the same result.
>
> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
> works as expected. Is the user:pass@server scheme no longer supported?
I get the same problem with trunk on Linux. I can fix it with this
patch but I'm not sure I understand all the consequences. Is there any
reason we should be hiding the password here?
Index: subversion/libsvn_ra_serf/options.c
===================================================================
--- subversion/libsvn_ra_serf/options.c (revision 1584323)
+++ subversion/libsvn_ra_serf/options.c (working copy)
@@ -245,7 +245,8 @@
(char *)svn_fspath__canonicalize(val, session->pool);
session->repos_root_str =
svn_urlpath__canonicalize(
- apr_uri_unparse(session->pool, &session->repos_root, 0),
+ apr_uri_unparse(session->pool, &session->repos_root,
+ APR_URI_UNP_REVEALPASSWORD),
session->pool);
}
else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) == 0)
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*