You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "D.J. Heap" <dj...@gmail.com> on 2006/09/14 01:00:30 UTC
Re: svn co problems
On 9/13/06, James Courtier-Dutton <Ja...@superbug.co.uk> wrote:
[snip]
> This is all on windows, using the binaries downloaded from the svn site.
> I do not know what they are linked against.
> I have done some checking.
> svn 1.3.1 works.
> svn 1.4.0 fails
>
> TortoiseSVN 1.4.0 works.
> TortoiseSVN 1.3.1 fails.
>
> Maybe someone who built those versions can answer your question.
1.4.0 was built with a newer neon (0.26.1), but I don't know if SSPI
support changed significantly in the new version. It looks like it
has to be explicitly enabled outside of the normal Subversion build
process and I doubt Brane did that with the 1.3.x releases, but I've
asked him about it so hopefully he can comment if he's not too busy.
I know the TSVN guys have played with SSPI quite a bit and disabled it
(at least they did for a while) due to Guest account issues or
something like that.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/13/06, D.J. Heap <dj...@gmail.com> wrote:
[snip]
>
> 1.4.0 was built with a newer neon (0.26.1), but I don't know if SSPI
> support changed significantly in the new version. It looks like it
> has to be explicitly enabled outside of the normal Subversion build
> process and I doubt Brane did that with the 1.3.x releases, but I've
> asked him about it so hopefully he can comment if he's not too busy.
> I know the TSVN guys have played with SSPI quite a bit and disabled it
> (at least they did for a while) due to Guest account issues or
> something like that.
>
I believe I have narrowed the issue down to a change in neon 0.26 --
by default it no longer supports SSPI/Neogiate authentication over
http, only https. This change appears to be due to the potential
danger of doing SSPI/Negotiate over http -- from the neon comments:
/* NE_AUTH_NEGOTIATE: Negotiate uses GSSAPI/SSPI to authenticate the
* user; an active attacker can modify any of the request/response at
* will, so this must not be used over an unsecured channel. */
So, you can either use https or use binaries built with neon 0.25.5 or
wait for a Subversion release that allows authentication types to be
configurable (for which I've posted a patch that will hopefully be
committed soon).
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by Daniel Rall <dl...@collab.net>.
On Sat, 16 Sep 2006, Peter Samuelson wrote:
>
> [Daniel Rall]
> > The fact that we didn't support 0.26.x in 1.4.0 seems slightly more
> > concerning, but since we will in 1.4.1, perhaps it's not a big deal.
>
> Is that the plan, then? So far not even trunk supports neon 0.26, in
> the sense of being included in configure.in $NEON_ALLOWED_LIST.
Especially given djh's findings/patch, I'm in favor of adding support
for 0.26.x to both trunk and our 1.4.x branch.
Re: svn co problems
Posted by Peter Samuelson <pe...@p12n.org>.
[Daniel Rall]
> The fact that we didn't support 0.26.x in 1.4.0 seems slightly more
> concerning, but since we will in 1.4.1, perhaps it's not a big deal.
Is that the plan, then? So far not even trunk supports neon 0.26, in
the sense of being included in configure.in $NEON_ALLOWED_LIST.
Re: svn co problems
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 14 Sep 2006, D.J. Heap wrote:
> On 9/14/06, Daniel Rall <dl...@collab.net> wrote:
> [snip]
> >
> >A data type for a parameter on the callback is different, no?
>
> Right, but it is never used or passed anywhere or anything...
DJ was referring to the "uri" parameter, rather than to the
lock_receiver callback, which is used in the svn_ra_dav__get_lock()
API, which is part of the RA library's vtable.
Anyhow, sounds like this isn't more than a compilation warning, a
minor issue.
The fact that we didn't support 0.26.x in 1.4.0 seems slightly more
concerning, but since we will in 1.4.1, perhaps it's not a big deal.
Re: svn co problems
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/14/06, Daniel Rall <dl...@collab.net> wrote:
[snip]
>
> A data type for a parameter on the callback is different, no?
>
Right, but it is never used or passed anywhere or anything...
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/14/06, James Courtier-Dutton <Ja...@superbug.co.uk> wrote:
[sinp]
>
> From my point of view, I would like both TortoiseSVN and the command
> line SVN, binaries for windows, to both work with each other. I.e. If
> one used TortoiseSVN to check out the repository from the apache server
> into a working copy, one should be able to run the command line "svn
> update" on the working copy.
> My current situation of TortoiseSVN 1.4.0 working, and SVN (command
> line) 1.3.1 working, results in incompatible working copies.
Sure, that is very reasonable, IMO. I plan on spending time this
weekend setting up and testing SSPI and attempting to add the dynaminc
SSPI configuration option that I think is available now with neon
0.26.1.
>
> Is there any possibility of combining TortoiseSVN and the command line
> SVN into a single TortoiseSVN binary package for windows?
That would be up to the TSVN folks.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by James Courtier-Dutton <Ja...@superbug.co.uk>.
Daniel Rall wrote:
> On Thu, 14 Sep 2006, D.J. Heap wrote:
>
>> On 9/14/06, Daniel Rall <dl...@collab.net> wrote:
>> [snip]
>>> The INSTALL and neon.m4 for 1.4.0 does not support Neon 0.26.x.
>>> Recently (r21490), a change did go into neon.m4 and
>>> subversion/libsvn_ra_dav/session.c to support 0.26.x for the autoconf
>>> build. Given the change to session.c, I'm somewhat surprised that
>>> Subversion 1.4.0 compiled against 0.26.x.
>> It compiles with a warning for an unused callback parameter and the
>> change just fixed that warning -- there was no functionality change at
>> all that I can see?
>
> A data type for a parameter on the callback is different, no?
>
> --- subversion/libsvn_ra_dav/session.c (revision 21489)
> +++ subversion/libsvn_ra_dav/session.c (revision 21490)
> @@ -1448,7 +1448,11 @@
> static void
> lock_receiver(void *userdata,
> const struct ne_lock *lock,
> +#ifdef SVN_NEON_0_26
> + const ne_uri *uri,
> +#else
> const char *uri,
> +#endif
> const ne_status *status)
> {
> struct receiver_baton *rb = userdata;
>
>
> Anyhow, is putting out a quick 1.4.1 necessary?
Re: svn co problems
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 14 Sep 2006, D.J. Heap wrote:
> On 9/14/06, Daniel Rall <dl...@collab.net> wrote:
> [snip]
> >
> >The INSTALL and neon.m4 for 1.4.0 does not support Neon 0.26.x.
> >Recently (r21490), a change did go into neon.m4 and
> >subversion/libsvn_ra_dav/session.c to support 0.26.x for the autoconf
> >build. Given the change to session.c, I'm somewhat surprised that
> >Subversion 1.4.0 compiled against 0.26.x.
>
> It compiles with a warning for an unused callback parameter and the
> change just fixed that warning -- there was no functionality change at
> all that I can see?
A data type for a parameter on the callback is different, no?
--- subversion/libsvn_ra_dav/session.c (revision 21489)
+++ subversion/libsvn_ra_dav/session.c (revision 21490)
@@ -1448,7 +1448,11 @@
static void
lock_receiver(void *userdata,
const struct ne_lock *lock,
+#ifdef SVN_NEON_0_26
+ const ne_uri *uri,
+#else
const char *uri,
+#endif
const ne_status *status)
{
struct receiver_baton *rb = userdata;
Anyhow, is putting out a quick 1.4.1 necessary?
Re: svn co problems
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/14/06, Daniel Rall <dl...@collab.net> wrote:
[snip]
>
> The INSTALL and neon.m4 for 1.4.0 does not support Neon 0.26.x.
> Recently (r21490), a change did go into neon.m4 and
> subversion/libsvn_ra_dav/session.c to support 0.26.x for the autoconf
> build. Given the change to session.c, I'm somewhat surprised that
> Subversion 1.4.0 compiled against 0.26.x.
>
It compiles with a warning for an unused callback parameter and the
change just fixed that warning -- there was no functionality change at
all that I can see?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 14 Sep 2006, Stefan Küng wrote:
> D.J. Heap wrote:
> >On 9/13/06, James Courtier-Dutton <Ja...@superbug.co.uk> wrote:
> >[snip]
> >>This is all on windows, using the binaries downloaded from the svn site.
> >>I do not know what they are linked against.
> >>I have done some checking.
> >>svn 1.3.1 works.
> >>svn 1.4.0 fails
> >>
> >>TortoiseSVN 1.4.0 works.
> >>TortoiseSVN 1.3.1 fails.
> >>
> >>Maybe someone who built those versions can answer your question.
> >
> >
> >1.4.0 was built with a newer neon (0.26.1), but I don't know if SSPI
>
> I don't think that Subversion currently really works with neon 0.26.1.
> TSVN 1.4.0-dev is linked against neon 0.25.5, the same version as TSVN
> 1.3.5. The only difference is that 1.3.x has neon built with HAVE_SSPI
> set to "" instead of "1".
The INSTALL and neon.m4 for 1.4.0 does not support Neon 0.26.x.
Recently (r21490), a change did go into neon.m4 and
subversion/libsvn_ra_dav/session.c to support 0.26.x for the autoconf
build. Given the change to session.c, I'm somewhat surprised that
Subversion 1.4.0 compiled against 0.26.x.
Re: svn co problems
Posted by Stefan Küng <to...@gmail.com>.
D.J. Heap wrote:
> On 9/14/06, Stefan Küng <to...@gmail.com> wrote:
> [snip]
>> In TSVN 1.3.x, I modified the config.hw file so that HAVE_SSPI was
>> removed there. That was the only way to disable SSPI from the build
>> script.
>>
>> Stefan
>>
>
> Ok. So are you planning on supporting SSPI in TSVN 1.4 or disabling
> it until the dynamic SSPI option is available?
It's enabled again in the TSVN 1.4.0RC1 and the nightlies. I just hope
that I won't get too much angry users complaining about it.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/14/06, Stefan Küng <to...@gmail.com> wrote:
[snip]
> In TSVN 1.3.x, I modified the config.hw file so that HAVE_SSPI was
> removed there. That was the only way to disable SSPI from the build script.
>
> Stefan
>
Ok. So are you planning on supporting SSPI in TSVN 1.4 or disabling
it until the dynamic SSPI option is available?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by Stefan Küng <to...@gmail.com>.
D.J. Heap wrote:
> On 9/14/06, Stefan Küng <to...@gmail.com> wrote:
> [snip]
>> > 1.4.0 was built with a newer neon (0.26.1), but I don't know if SSPI
>>
>> I don't think that Subversion currently really works with neon 0.26.1.
>> TSVN 1.4.0-dev is linked against neon 0.25.5, the same version as TSVN
>> 1.3.5. The only difference is that 1.3.x has neon built with HAVE_SSPI
>> set to "" instead of "1".
>
>
> It does build and pass all tests. It looks like HAVE_SSPI is always
> set on Windows (in config.hw) -- do you have to pass it to the make
> file anyway?
In TSVN 1.3.x, I modified the config.hw file so that HAVE_SSPI was
removed there. That was the only way to disable SSPI from the build script.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/14/06, Stefan Küng <to...@gmail.com> wrote:
[snip]
> > 1.4.0 was built with a newer neon (0.26.1), but I don't know if SSPI
>
> I don't think that Subversion currently really works with neon 0.26.1.
> TSVN 1.4.0-dev is linked against neon 0.25.5, the same version as TSVN
> 1.3.5. The only difference is that 1.3.x has neon built with HAVE_SSPI
> set to "" instead of "1".
It does build and pass all tests. It looks like HAVE_SSPI is always
set on Windows (in config.hw) -- do you have to pass it to the make
file anyway?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by "G.J. Doornink" <dk...@xs4all.nl>.
D.J. Heap wrote:
>
> Did you have to do anything special to enable SSPI in 0.26.1?
>
> DJ
No, SSPI is by default turned on in neon 0.26.1 (and neon 0.25.5).
I used to have to explicitely turn off SSPI for subversion 1.3.2 by
commenting the HAVE_SSPI define in config.hw (and config.hw.in).
Otherwise I would have the problem that neon would not always use the
user name (and password) of the interactively logged on user. Also
specifying the user name and password on the svn command line would have
no effect.
With subversion 1.4.0 and neon 0.26.1 both problems seem to have been
resolved.
But to be honest, I couldn't tell you for sure if SSPI works, or fails
altogether. :)
If I clear the auth cache, subversion does prompt me for my password
(for the interactively logged on user), and I can't at the moment
remember whether that's supposed to happen.
Kind regards,
Gerrit Jan
--
G.J. Doornink <dk...@xs4all.nl>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/14/06, G.J. Doornink <dk...@xs4all.nl> wrote:
> Stefan Küng wrote:
> >
> > I don't think that Subversion currently really works with neon 0.26.1.
> > TSVN 1.4.0-dev is linked against neon 0.25.5, the same version as TSVN
> > 1.3.5. The only difference is that 1.3.x has neon built with HAVE_SSPI
> > set to "" instead of "1".
> >
> > Stefan
> >
>
> FWIW, subversion 1.4.0 with neon 0.26.1 AND SSPI enabled works for me
> with Apache 2.0.58 and mod_auth_sspi.
>
> I haven't performed all possible tests with this setup, but the basic
> commands work.
>
> Neon even passes the username and password as specified with the svn
> --username and --password command line options to the sspi auth apache
> module. This is something that would not happen with an SSPI enabled svn
> 1.3.2 with neon 0.25.5.
>
> Kind regards,
>
> Gerrit Jan
>
Did you have to do anything special to enable SSPI in 0.26.1?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by "G.J. Doornink" <dk...@xs4all.nl>.
Stefan Küng wrote:
>
> I don't think that Subversion currently really works with neon 0.26.1.
> TSVN 1.4.0-dev is linked against neon 0.25.5, the same version as TSVN
> 1.3.5. The only difference is that 1.3.x has neon built with HAVE_SSPI
> set to "" instead of "1".
>
> Stefan
>
FWIW, subversion 1.4.0 with neon 0.26.1 AND SSPI enabled works for me
with Apache 2.0.58 and mod_auth_sspi.
I haven't performed all possible tests with this setup, but the basic
commands work.
Neon even passes the username and password as specified with the svn
--username and --password command line options to the sspi auth apache
module. This is something that would not happen with an SSPI enabled svn
1.3.2 with neon 0.25.5.
Kind regards,
Gerrit Jan
--
G.J. Doornink <dk...@xs4all.nl>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn co problems
Posted by Stefan Küng <to...@gmail.com>.
D.J. Heap wrote:
> On 9/13/06, James Courtier-Dutton <Ja...@superbug.co.uk> wrote:
> [snip]
>> This is all on windows, using the binaries downloaded from the svn site.
>> I do not know what they are linked against.
>> I have done some checking.
>> svn 1.3.1 works.
>> svn 1.4.0 fails
>>
>> TortoiseSVN 1.4.0 works.
>> TortoiseSVN 1.3.1 fails.
>>
>> Maybe someone who built those versions can answer your question.
>
>
> 1.4.0 was built with a newer neon (0.26.1), but I don't know if SSPI
I don't think that Subversion currently really works with neon 0.26.1.
TSVN 1.4.0-dev is linked against neon 0.25.5, the same version as TSVN
1.3.5. The only difference is that 1.3.x has neon built with HAVE_SSPI
set to "" instead of "1".
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org