You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2005/08/10 19:18:14 UTC
svn 1.2.2 tarballs are up for testing/voting
1.2.2 tarballs are up for testing. 1.2.2 was cut from r15671 on the
1.2.x branch.
Committers: please test, vote, and send your sigs!
Non-committers: please test anyway. :-)
Hopefully we'll see a final 1.2.2 release in the next couple of days.
Tarballs are up at http://fornix.brain.org/subversion/
-rw-rw-r-- 1 svnrm svnrm 7235030 Aug 10 15:06 subversion-1.2.2.tar.bz2
-rw-rw-r-- 1 svnrm svnrm 8873107 Aug 10 15:06 subversion-1.2.2.tar.gz
-rw-rw-r-- 1 svnrm svnrm 11718604 Aug 10 15:11 subversion-1.2.2.zip
md5sums:
1e52c75277a17909ab606d992587975c subversion-1.2.2.tar.bz2
a7615c4db9f5e23d643f77ecd123cc7e subversion-1.2.2.tar.gz
2fd825e3a5104a5e5dcb0654fd86d931 subversion-1.2.2.zip
sha1sums:
a45ec89444086e7f8ca429ade7ee1ea3526db671 subversion-1.2.2.tar.bz2
84ba9fd2935ed4c5d2c095a3213191fbb5c52c6b subversion-1.2.2.tar.gz
484a7327aa71e485b19b251d98b14cea294434cf subversion-1.2.2.zip
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by steveking <st...@gmx.ch>.
Ben Reser wrote:
> 1.2.2 tarballs are up for testing. 1.2.2 was cut from r15671 on the
> 1.2.x branch.
>
> Committers: please test, vote, and send your sigs!
>
> Non-committers: please test anyway. :-)
Just built the windows svn.exe from the 1.2.x branch (rev 15665).
The crash I reported before still happens:
svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/API test
cd test
svn lock Doxyfile
now I'm asked three times for username/password, then svn.exe crashes.
My guess is that svn_ra_dav__maybe_store_auth_info_after_result() checks
for SVN_ERR_RA_NOT_AUTHORIZED to avoid the crash, but since locking
isn't supported on pre 1.2 servers the returned error is something else
(not implemented). Then that check fails and the function tries to store
the auth data which isn't available.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Aug 12, 2005, at 7:15 AM, Branko Čibej wrote:
>
>>>
>>> It's possible the different behaviour is due to a different auth setup
>>> between the tsvn server and my server. I used httpd to require
>>> read/write auth for all access, tsvn uses mod_auth_svn and probably
>>> allows read-only access as well as read/write access.
>>>
>>>
>> D'you know, I think you're right! The damn mod_authz_svn takes it
>> upon itself to return HTTP_UNAUTHORIZED in the auth_checker hook,
>> even though it's thecking authorization, not authentication. I think
>> this is a bug in mod_authz_svn. It should be returning
>> HTTP_FORBIDDEN (as in the access_checker hook), and probably
>> shouldn't provide an auth checker at all.
>
>
>
> CEE (tigris.org) doesn't use mod_authz_svn, but a proprietary module
> called mod_auth_svn. The name is deliberately ambiguous, because it
> registers itself as both an authn and authz hook with apache. It
> performs authn by checking the basic-auth-creds against a central CEE
> database, and performs authz by checking paths against another
> central CEE database.
Indeed, I was a bit quick off the mark here. I tested with a local
svn-1.1.1 over http with mod_authz_svn configured, and I still get a
405, not a 401. So it looks like the bug is in that mod_auth_svn?
Anyway, I've decided to commit Philip's patch, which avoids all auth
caching in this situation.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 12, 2005, at 7:15 AM, Branko Čibej wrote:
>>
>> It's possible the different behaviour is due to a different auth
>> setup
>> between the tsvn server and my server. I used httpd to require
>> read/write auth for all access, tsvn uses mod_auth_svn and probably
>> allows read-only access as well as read/write access.
>>
>>
> D'you know, I think you're right! The damn mod_authz_svn takes it
> upon itself to return HTTP_UNAUTHORIZED in the auth_checker hook,
> even though it's thecking authorization, not authentication. I
> think this is a bug in mod_authz_svn. It should be returning
> HTTP_FORBIDDEN (as in the access_checker hook), and probably
> shouldn't provide an auth checker at all.
CEE (tigris.org) doesn't use mod_authz_svn, but a proprietary module
called mod_auth_svn. The name is deliberately ambiguous, because it
registers itself as both an authn and authz hook with apache. It
performs authn by checking the basic-auth-creds against a central CEE
database, and performs authz by checking paths against another
central CEE database.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Justin Erenkrantz <ju...@erenkrantz.com> writes:
>
>
>
>>On Fri, Aug 12, 2005 at 05:18:04AM +0200, Branko ?ibej wrote:
>>
>>
>>>I don't think we can do anything about the repeated authn prompts --
>>>IMHO they're caused by a server bug. I verified that this doesn't happen
>>>with httpd-2.0.54/svn-1.1.1 on Windows, and IIRC Philip verified
>>>httpd-2.0.54/svn-1.1.4 on *nix.
>>>
>>>
>>Nothing particularly jumps out at me that would have changed between httpd
>>2.0.50 and 2.0.54 that would affect this. -- justin
>>
>>
>
>It's possible the different behaviour is due to a different auth setup
>between the tsvn server and my server. I used httpd to require
>read/write auth for all access, tsvn uses mod_auth_svn and probably
>allows read-only access as well as read/write access.
>
>
D'you know, I think you're right! The damn mod_authz_svn takes it upon
itself to return HTTP_UNAUTHORIZED in the auth_checker hook, even though
it's thecking authorization, not authentication. I think this is a bug
in mod_authz_svn. It should be returning HTTP_FORBIDDEN (as in the
access_checker hook), and probably shouldn't provide an auth checker at all.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> On Fri, Aug 12, 2005 at 05:18:04AM +0200, Branko ?ibej wrote:
>> I don't think we can do anything about the repeated authn prompts --
>> IMHO they're caused by a server bug. I verified that this doesn't happen
>> with httpd-2.0.54/svn-1.1.1 on Windows, and IIRC Philip verified
>> httpd-2.0.54/svn-1.1.4 on *nix.
>
> Nothing particularly jumps out at me that would have changed between httpd
> 2.0.50 and 2.0.54 that would affect this. -- justin
It's possible the different behaviour is due to a different auth setup
between the tsvn server and my server. I used httpd to require
read/write auth for all access, tsvn uses mod_auth_svn and probably
allows read-only access as well as read/write access.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn lock" crash against certain 1.1.x servers [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Aug 12, 2005 at 05:18:04AM +0200, Branko ?ibej wrote:
> But I think the root of the problem is that the tigris.org server
> (httpd-2.0.50/svn-1.1.1 + patches) returns 401
> (Unauthorized/Authentication Required) when it sees the LOCK that it
> can't handle, instead of returning 405 (Method Not Allowed). Because of
> that, Neon will keep retrying with new auth data until we run out of
> providers, then return NE_ERROR -- not NE_AUTH -- which we don't handle
> specially, so we end up calling svn_ra_dav__maybe_store_auth_info.
>
> I don't think we can do anything about the repeated authn prompts --
> IMHO they're caused by a server bug. I verified that this doesn't happen
> with httpd-2.0.54/svn-1.1.1 on Windows, and IIRC Philip verified
> httpd-2.0.54/svn-1.1.4 on *nix.
Nothing particularly jumps out at me that would have changed between httpd
2.0.50 and 2.0.54 that would affect this. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
"svn lock" crash against certain 1.1.x servers [was: Re: svn 1.2.2
tarballs are up for testing/voting]
Posted by Branko Čibej <br...@xbc.nu>.
O.K., here's the repro provided by Stefan again, for the record:
svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/API test
cd test
svn lock Doxyfile
The client will ask for credentials several times (once for each
provider?), then crash.
The direct cause of the crash is in svn_auth_save_credentials, where the
provider index in the incoming svn_auth_iterstate_t is out of bounds,
and we don't do any bounds checking before pulling stuff from the
providers array. This part is easily fixed -- I'm testing the following
patch:
Index: subversion/libsvn_subr/auth.c
===================================================================
--- subversion/libsvn_subr/auth.c (revision 15686)
+++ subversion/libsvn_subr/auth.c (working copy)
@@ -314,16 +314,19 @@
return SVN_NO_ERROR;
/* First, try to save the creds using the provider that produced them. */
- provider = APR_ARRAY_IDX (state->table->providers,
- state->provider_idx,
- svn_auth_provider_object_t *);
- if (provider->vtable->save_credentials)
- SVN_ERR (provider->vtable->save_credentials (&save_succeeded,
- creds,
- provider->provider_baton,
- auth_baton->parameters,
- state->realmstring,
- pool));
+ if (state->table->providers->nelts > state->provider_idx)
+ {
+ provider = APR_ARRAY_IDX (state->table->providers,
+ state->provider_idx,
+ svn_auth_provider_object_t *);
+ if (provider->vtable->save_credentials)
+ SVN_ERR (provider->vtable->save_credentials (&save_succeeded,
+ creds,
+ provider->provider_baton,
+ auth_baton->parameters,
+ state->realmstring,
+ pool));
+ }
if (save_succeeded)
return SVN_NO_ERROR;
But I think the root of the problem is that the tigris.org server
(httpd-2.0.50/svn-1.1.1 + patches) returns 401
(Unauthorized/Authentication Required) when it sees the LOCK that it
can't handle, instead of returning 405 (Method Not Allowed). Because of
that, Neon will keep retrying with new auth data until we run out of
providers, then return NE_ERROR -- not NE_AUTH -- which we don't handle
specially, so we end up calling svn_ra_dav__maybe_store_auth_info.
I don't think we can do anything about the repeated authn prompts --
IMHO they're caused by a server bug. I verified that this doesn't happen
with httpd-2.0.54/svn-1.1.1 on Windows, and IIRC Philip verified
httpd-2.0.54/svn-1.1.4 on *nix.
Can (or should) we do something about the NE_ERROR in
svn_ra_dav__convert_error and/or
svn_ra_dav__maybe_store_auth_info_after_result?
Branko Čibej wrote:
> steveking wrote:
>
>> Branko Čibej wrote:
>>
>>> So, whatever it is, it's either fixed on trunk, or the repro isn't
>>> complete.
>>
>>
>>
>> It's not necessary to delete the auth cache. Ben Collins-Sussman
>> explained to me that if the server doesn't know the lock command,
>> Apache doesn't know that and assumes that the auth failed. So it's
>> not important that the auth cache is cleared or what
>> username/password you enter. It will always be rejected.
>
>
> That's obviously not true. As I said, the trunk build caches the auth
> info even when the lock request fails. I think 1.2.0 doesn't, though.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Branko Čibej <br...@xbc.nu>.
steveking wrote:
> Branko Čibej wrote:
>
>> So, whatever it is, it's either fixed on trunk, or the repro isn't
>> complete.
>
>
> It's not necessary to delete the auth cache. Ben Collins-Sussman
> explained to me that if the server doesn't know the lock command,
> Apache doesn't know that and assumes that the auth failed. So it's not
> important that the auth cache is cleared or what username/password you
> enter. It will always be rejected.
That's obviously not true. As I said, the trunk build caches the auth
info even when the lock request fails. I think 1.2.0 doesn't, though.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by steveking <st...@gmx.ch>.
Branko Čibej wrote:
> Mark Phippard wrote:
>
>> No one has commented on the issue that Stefan King raised. It looks
>> simple enough to test and if I recall the problem is not specific to
>> Windows so it could be verified anywhere:
>>
>>
> I can't reproduce this, using a stock 1.2.0 client against a 1.1.4
> mod_dav_svn, both running on Windows:
The bug isn't in 1.2.0, only in 1.2.1 and of course 1.2.2.
The bug was introduced in 1.2.1 because of the change:
* fixed: 'svn (un)lock' not caching authentication (r15088)
You can use your own official 1.2.1 build - it will crash too.
> So I tried with the current trunk (slightly instrumented in
> libsvn_ra_dav/util.c, to print the raw Neon error and the converted
> error); again, no luck:
So maybe it's fixed in HEAD, haven't tested that yet (will do, stay tuned).
> O.K., so I see that tortoisesvn.tigris.org is a 1.1.1 server; trying
> with that... remember to delete the auth cache... no luck. Same as
> before, no crash, auth info gets stored even though the lock request
> itself fails.
>
> So, whatever it is, it's either fixed on trunk, or the repro isn't
> complete.
It's not necessary to delete the auth cache. Ben Collins-Sussman
explained to me that if the server doesn't know the lock command, Apache
doesn't know that and assumes that the auth failed. So it's not
important that the auth cache is cleared or what username/password you
enter. It will always be rejected.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Mark Phippard <Ma...@softlanding.com>.
SteveKing <st...@gmx.ch> wrote on 08/11/2005 03:12:47 PM:
> Branko Čibej wrote:
>
> > Well, no luck, the exe from the 1.2.2 tarball works for me:
> >
> > $
../../rel/subversion-1.2.2/Release/subversion/clients/cmdline/svn.exe
> > lock foo --username jrandom
> > Authentication realm: <http://localhost:80> Subversion Testing
> > Password for 'jrandom': *********
> > svn: Lock request failed: 405 Method Not Allowed (http://localhost)
>
> If I delete the auth cache on my harddrive first, then I don't get a
> crash either, but I get
>
> > So it seems that the bug is fixed in 1.2.2, too.
>
> Can you try with a repository where you have commit access (1.1.1
> server) and your auth data already cached?
>
> If I do an
> svn lock d:\Development\SVN\TortoiseSVN\build.bat
> on my working copy of TSVN with my auth data cached, I get a crash.
Have you tried to run svn st -u? Isn't that where this fix was made? Your
experiences would imply that could still be broken as well.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by SteveKing <st...@gmx.ch>.
Branko Čibej wrote:
> Well, no luck, the exe from the 1.2.2 tarball works for me:
>
> $ ../../rel/subversion-1.2.2/Release/subversion/clients/cmdline/svn.exe
> lock foo --username jrandom
> Authentication realm: <http://localhost:80> Subversion Testing
> Password for 'jrandom': *********
> svn: Lock request failed: 405 Method Not Allowed (http://localhost)
If I delete the auth cache on my harddrive first, then I don't get a
crash either, but I get
\Development\Svn\TortoiseSVN\ext\Subversion\subversion\libsvn_ra_dav\util.c:780:
(apr_err=170001)
svn: PROPFIND request failed on '/svn/tortoisesvn/trunk/build.bat'
\Development\Svn\TortoiseSVN\ext\Subversion\subversion\libsvn_ra_dav\util.c:295:
(apr_err=170001)
svn: PROPFIND of '/svn/tortoisesvn/trunk/build.bat': authorization
failed (http:
//tortoisesvn.tigris.org)
('authorization failed' instead of what you get 'method not allowed').
> So it seems that the bug is fixed in 1.2.2, too.
Can you try with a repository where you have commit access (1.1.1
server) and your auth data already cached?
If I do an
svn lock d:\Development\SVN\TortoiseSVN\build.bat
on my working copy of TSVN with my auth data cached, I get a crash.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 11 Aug 2005, Philip Martin wrote:
> Branko ?ibej <br...@xbc.nu> writes:
...
> tigris.org claims to be running httpd 2.0.50 with mod_dav_svn 1.1.1,
> my local server is Debian's httpd 2.0.54-4 with mod_dav_svn 1.1.4-2.
It is what it claims to be, with a small patch to httpd's mod_headers,
and some bug fix patches to subversion (from 1.1.2+).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:
> Philip Martin wrote:
>>
>>I don't get a crash when I try to reproduce the problem against a
>>local 1.1.4 server.
>>
> I didn't get a crash when I tested against a local server, either, but
> then I probably have a newer httpd than the one that's running on
> tigris.org. That could make a difference.
I suppose it could be mod_dav_svn or httpd.
tigris.org claims to be running httpd 2.0.50 with mod_dav_svn 1.1.1,
my local server is Debian's httpd 2.0.54-4 with mod_dav_svn 1.1.4-2.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>With write access to the tsvn repo, I can confirm this -- both 1.2.2
>>and trunk.
>>
>>Stefan, thanks, you can revoke my write access now.
>>
>>
>
>I appear to have (write?) access, and yes I also get a crash.
>
>I don't get a crash when I try to reproduce the problem against a
>local 1.1.4 server.
>
>
I didn't get a crash when I tested against a local server, either, but
then I probably have a newer httpd than the one that's running on
tigris.org. That could make a difference.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] storing auth after auth failure
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>>- if (! state)
>>>+ if (! state || state->table->providers->nelts == state->provider_idx)
>>> return SVN_NO_ERROR;
>>>
>>>
>>>
>>>
>>I think we should go ahead and store the auth info anyway, as I do in
>>my patch.
>>
>>
>
>Hmm, as far as I can see your patch doesn't store the auth info
>either. I don't mind which patch you commit as I think they have the
>same effect :)
>
>
Your patch makes save_creds bail out if the initial provider index is
out of range. My patch just skips the initial creds save with the
"default" provider, but still goes through the loop -- which,
presumably, will save the authn info.
Maybe we can toss a coin to decide which patch goes in. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] storing auth after auth failure
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:
>>- if (! state)
>>+ if (! state || state->table->providers->nelts == state->provider_idx)
>> return SVN_NO_ERROR;
>>
>>
> I think we should go ahead and store the auth info anyway, as I do in
> my patch.
Hmm, as far as I can see your patch doesn't store the auth info
either. I don't mind which patch you commit as I think they have the
same effect :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] storing auth after auth failure
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>
>>Branko Čibej <br...@xbc.nu> writes:
>>
>>
>>
>>>With write access to the tsvn repo, I can confirm this -- both 1.2.2
>>>and trunk.
>>>
>>>Stefan, thanks, you can revoke my write access now.
>>>
>>>
>>I appear to have (write?) access, and yes I also get a crash.
>>
>>
>
>I stepped through trunk client aginst tsvn server:
>
>
[...]
Well! Beat me by 8 minutes. :)
>- if (! state)
>+ if (! state || state->table->providers->nelts == state->provider_idx)
> return SVN_NO_ERROR;
>
>
I think we should go ahead and store the auth info anyway, as I do in my
patch. What we're seeing here is a server bug that we can't really
detect and work around in the client.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] storing auth after auth failure
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Branko Čibej <br...@xbc.nu> writes:
>
>> With write access to the tsvn repo, I can confirm this -- both 1.2.2
>> and trunk.
>>
>> Stefan, thanks, you can revoke my write access now.
>
> I appear to have (write?) access, and yes I also get a crash.
I stepped through trunk client aginst tsvn server:
a) the client calls svn_ra_dav__lock
b) svn_ra_dav__lock calls shim_svn_ra_dav__lock
c) shim_svn_ra_dav__lock calls svn_ra_dav__get_baseline_info which
prompts for auth and succeeds
d) shim_svn_ra_dav__lock calls ne_lock which prompts for auth three
times, the first prompt is for a password, the second and third
prompts are for both username and password.
e) the ne_lock call fails and returns 1 (or NE_ERROR)
f) shim_svn_ra_dav__lock calls svn_ra_dav__convert_error which
creates an SVN_ERR_RA_DAV_REQUEST_FAILED error
g) shim_svn_ra_dav__lock returns to svn_ra_dav__lock
h) svn_ra_dav__lock
calls
svn_ra_dav__maybe_store_auth_info_after_result
which calls
svn_ra_dav__maybe_store_auth_info
which calls
svn_auth_save_credentials
i) svn_auth_save_credentials retieves a NULL provider and then SEGVs
accessing provider->vtable->save_credentials
I don't really understand the auth stuff, but I think the fact that
(d) prompts three times indicates that the auth is failing. It seems
that there are two things that could be considered bugs:
1) the ra_dav code does not recognise the error as an auth failure
because ne_lock returns NE_ERROR rather than NE_AUTH (I'm using
neon 0.24.7)
2) the auth code crashes when asked to store auth after an auth
failure
I don't know whether, or how, we should fix (1) but I can fix (2)
using this:
Index: subversion/libsvn_subr/auth.c
===================================================================
--- subversion/libsvn_subr/auth.c (revision 15679)
+++ subversion/libsvn_subr/auth.c (working copy)
@@ -297,7 +297,7 @@
svn_auth_baton_t *auth_baton;
void *creds;
- if (! state)
+ if (! state || state->table->providers->nelts == state->provider_idx)
return SVN_NO_ERROR;
auth_baton = state->auth_baton;
and then the client gives me
$ svn lock wc/Doxyfile --username guest
...
svn: Lock request failed: 401 Authorization Required (http://tortoisesvn.tigris.org)
I don't know whether it's sensible to silently do nothing when storing
auth after an auth failure, perhaps an error should be returned.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Mark Phippard <Ma...@softlanding.com>.
SteveKing <st...@gmx.ch> wrote on 08/11/2005 04:36:27 PM:
> Mark Phippard wrote:
>
> >>I appear to have (write?) access, and yes I also get a crash.
> >>
> >>I don't get a crash when I try to reproduce the problem against a
> >>local 1.1.4 server.
> >
> >
> > I do not think write access has anything to do with it. I used
> > credentials of guest/guest against TSVN repos and I got the crash.
>
> Maybe not write access, but you must have your auth data cached on disk
> to make it crash.
Correct. When I did the svn co I gave it guest/guest for credentials and
let it cache it.
As you are well aware, the tigris.org repositories require credentials
even for reading.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by SteveKing <st...@gmx.ch>.
Mark Phippard wrote:
>>I appear to have (write?) access, and yes I also get a crash.
>>
>>I don't get a crash when I try to reproduce the problem against a
>>local 1.1.4 server.
>
>
> I do not think write access has anything to do with it. I used
> credentials of guest/guest against TSVN repos and I got the crash.
Maybe not write access, but you must have your auth data cached on disk
to make it crash.
But since other people now can reproduce the crash, I don't think that
my build is broken anymore ;)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Mark Phippard <Ma...@softlanding.com>.
Philip Martin <ph...@codematters.co.uk> wrote on 08/11/2005 04:20:42 PM:
> Branko Čibej <br...@xbc.nu> writes:
>
> > With write access to the tsvn repo, I can confirm this -- both 1.2.2
> > and trunk.
> >
> > Stefan, thanks, you can revoke my write access now.
>
> I appear to have (write?) access, and yes I also get a crash.
>
> I don't get a crash when I try to reproduce the problem against a
> local 1.1.4 server.
I do not think write access has anything to do with it. I used
credentials of guest/guest against TSVN repos and I got the crash.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:
> With write access to the tsvn repo, I can confirm this -- both 1.2.2
> and trunk.
>
> Stefan, thanks, you can revoke my write access now.
I appear to have (write?) access, and yes I also get a crash.
I don't get a crash when I try to reproduce the problem against a
local 1.1.4 server.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by Branko Čibej <br...@xbc.nu>.
SteveKing wrote:
> Mark Phippard wrote:
>
>> OK, I just built 1.2.2 from the zip and did this test. I get the
>> same thing as you, except svn crashes at the end when I do it.
>
>
> It also crashes for me, but only if I have my auth data already
> stored. If I clean the auth cache on my harddrive, then I just get an
> 'authorization failed' without a crash.
> And it also only crashes if I *don't* give --username and/or
> --password on the commandline.
>
> I've sent Branko my auth folder via PM (hope he doesn't try to crack
> the password :) ) to try. But I'm not even sure that will help: the
> auth data is encrypted now and I think windows won't let him decrypt
> it (haven't thought of that before I sent him the zip file).
>
>> I thought I would try svn st -u after to see if that had the
>> problem. It seems to work OK.
>
>
> I've tested the 'svn st -u' with the 1.2.2 and that works. Ben has
> fixed that really good.
>
> I've just built svn from HEAD, and it too crashes.
>
> So I'll try to get together what we found out so far:
>
> $ svn lock file
> with client 1.2.1 up to 1.2.2 (and HEAD) can crash if
> - the lock is done to a http server 1.1.1 (like tigris.org)
> - the user has commit access to the repository
> - the user has the auth data cached on disk
> - no --username and/or --password is given on the command line
With write access to the tsvn repo, I can confirm this -- both 1.2.2 and
trunk.
Stefan, thanks, you can revoke my write access now.
Anyway, I think doesn't make sense to ship 1.2.2 with such a bug.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by SteveKing <st...@gmx.ch>.
Mark Phippard wrote:
> OK, I just built 1.2.2 from the zip and did this test. I get the same
> thing as you, except svn crashes at the end when I do it.
It also crashes for me, but only if I have my auth data already stored.
If I clean the auth cache on my harddrive, then I just get an
'authorization failed' without a crash.
And it also only crashes if I *don't* give --username and/or --password
on the commandline.
I've sent Branko my auth folder via PM (hope he doesn't try to crack the
password :) ) to try. But I'm not even sure that will help: the auth
data is encrypted now and I think windows won't let him decrypt it
(haven't thought of that before I sent him the zip file).
> I thought I would try svn st -u after to see if that had the problem. It
> seems to work OK.
I've tested the 'svn st -u' with the 1.2.2 and that works. Ben has fixed
that really good.
I've just built svn from HEAD, and it too crashes.
So I'll try to get together what we found out so far:
$ svn lock file
with client 1.2.1 up to 1.2.2 (and HEAD) can crash if
- the lock is done to a http server 1.1.1 (like tigris.org)
- the user has commit access to the repository
- the user has the auth data cached on disk
- no --username and/or --password is given on the command line
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by Mark Phippard <Ma...@softlanding.com>.
Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 03:16:40 PM:
> Well, well, well. All three, 1.2.0, 1.2.2 and trunk fail here. And the
> server returns a _different_ error code than in my local tests. Here's
> the result from trunk:
>
> $ ../../repos/svn-trunk/Release/subversion/clients/cmdline/svn.exe lock
Doxyfile
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Password for 'brane': *********
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Password for 'brane': *********
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Username: brane
> Password for 'brane': *********
> Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM
Repository
> Username: brane
> Password for 'brane': *********
> NEON_ERR 1 401 Authorization Required
> SVN_ERR 175002 Lock request failed: 401 Authorization Required
(http://tortoises
> vn.tigris.org)
>
>
> Trunk then crashes. 1.2.0 doesn't, neither does 1.2.2, it seems.
OK, I just built 1.2.2 from the zip and did this test. I get the same
thing as you, except svn crashes at the end when I do it.
I thought I would try svn st -u after to see if that had the problem. It
seems to work OK.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
1.2.2 is not ready [was: Re: svn 1.2.2 tarballs are up for testing/voting]
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 02:55:20 PM:
>
>
>>So it seems that the bug is fixed in 1.2.2, too.
>>
>>
>
>That is good, but is there any way you could just try Stefan's test
>against tigris.org to be sure? I think he reduced it something pretty
>simple.
>
>svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/API test
>cd test
>svn lock Doxyfile
>
>Maybe Stefan just did something wrong in his build, or his test picked up
>the old executable? It can't hurt to do the exact same test. The URL he
>gave just has two files in it.
>
>
Sure, I'll try this...
[5 minutes later]
Well, well, well. All three, 1.2.0, 1.2.2 and trunk fail here. And the
server returns a _different_ error code than in my local tests. Here's
the result from trunk:
$ ../../repos/svn-trunk/Release/subversion/clients/cmdline/svn.exe lock Doxyfile
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Password for 'brane': *********
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Password for 'brane': *********
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Username: brane
Password for 'brane': *********
Authentication realm: <http://tortoisesvn.tigris.org:80> CollabNet SCM Repository
Username: brane
Password for 'brane': *********
NEON_ERR 1 401 Authorization Required
SVN_ERR 175002 Lock request failed: 401 Authorization Required (http://tortoises
vn.tigris.org)
Trunk then crashes. 1.2.0 doesn't, neither does 1.2.2, it seems.
The only difference between my local test and the remote tigris.org test
is that a) my server is Windows, and b) I use httpd-2.0.54, while
tigris.org presumably doesn't. So it looks like a combination of mod_dav
bug and svn client bug.
I think this is serious enough to hold up the 1.2.2 release, espeially
as I see new warnings in the Windows build of the Python bindings, too:
subversion\bindings\swig\python\core.c(2938) : warning C4047: '=' : 'struct _object *' differs in levels of indirection from 'struct apr_array_header_t ** '
subversion\bindings\swig\python\core.c(2941) : warning C4047: '=' : 'struct _object *' differs in levels of indirection from 'struct apr_array_header_t ** '
subversion\bindings\swig\python\core.c(2944) : warning C4047: '=' : 'struct _object *' differs in levels of indirection from 'struct apr_array_header_t ** '
subversion\bindings\swig\python\core.c(6164) : warning C4013: 'svn_utf_initialize' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6212) : warning C4013: 'svn_utf_stringbuf_to_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6287) : warning C4013: 'svn_utf_string_to_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6345) : warning C4013: 'svn_utf_cstring_to_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6405) : warning C4013: 'svn_utf_cstring_to_utf8_ex' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6476) : warning C4013: 'svn_utf_stringbuf_from_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6551) : warning C4013: 'svn_utf_string_from_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6609) : warning C4013: 'svn_utf_cstring_from_utf8' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6669) : warning C4013: 'svn_utf_cstring_from_utf8_ex' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6724) : warning C4013: 'svn_utf_cstring_from_utf8_fuzzy' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6770) : warning C4013: 'svn_utf_cstring_from_utf8_stringbuf' undefined; assuming extern returning int
subversion\bindings\swig\python\core.c(6843) : warning C4013: 'svn_utf_cstring_from_utf8_string' undefined; assuming extern returning int
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Mark Phippard <Ma...@softlanding.com>.
Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 02:55:20 PM:
> > Ah, I misunderstood. I'm building the 1.2.2 sources now (to sign the
> > tarball), and will test with that. I agree this should be fixed in
> > 1.2.2 if it's fixed on trunk.
>
> Well, no luck, the exe from the 1.2.2 tarball works for me:
>
> $ ../../rel/subversion-1.2.2/Release/subversion/clients/cmdline/svn.exe
lock
> foo --username jrandom
> Authentication realm: <http://localhost:80> Subversion Testing
> Password for 'jrandom': *********
> svn: Lock request failed: 405 Method Not Allowed (http://localhost)
> $ wget --http-user=jrandom --http-passwd=rayjandom -O -
http://localhost/test-dav/
> --20:51:25-- http://localhost/test-dav/
> => `-'
> Resolving localhost... 127.0.0.1
> Connecting to localhost[127.0.0.1]:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 251 [text/html]
> <html><head><title>Revision 1: /</title></head>
> <body>
> <h2>Revision 1: /</h2>
> <ul>
> <li><a href="foo">foo</a></li>
> </ul>
> <hr noshade><em>Powered by <a href="http://subversion.tigris.org/
> ">Subversion</a> version 1.1.1 (r11581).</em>
>
>
> So it seems that the bug is fixed in 1.2.2, too.
That is good, but is there any way you could just try Stefan's test
against tigris.org to be sure? I think he reduced it something pretty
simple.
svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/API test
cd test
svn lock Doxyfile
Maybe Stefan just did something wrong in his build, or his test picked up
the old executable? It can't hurt to do the exact same test. The URL he
gave just has two files in it.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Mark Phippard wrote:
>
>> Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 02:09:17 PM:
>>
>>
>>
>>>Mark Phippard wrote:
>>>
>>>
>>>
>>>
>>>
>>>> No one has commented on the issue that Stefan King raised. It
>>>> looks simple enough to test and if I recall the problem is not
>>>> specific to Windows so it could be verified anywhere:
>>>>
>>>>
>>>>
>>>
>>> I can't reproduce this, using a stock 1.2.0 client against a 1.1.4
>>> mod_dav_svn, both running on Windows:
>>>
>>
>>
>> This is specifically a bug in 1.2.1. It is supposed to be one of the
>> things fixed in 1.2.2 which is why Stefan was reporting that he still
>> saw the problem. Perhaps he did something wrong in his build, but
>> testing with the 1.2.2 client is what needs to be done.
>>
>>
> Ah, I misunderstood. I'm building the 1.2.2 sources now (to sign the
> tarball), and will test with that. I agree this should be fixed in
> 1.2.2 if it's fixed on trunk.
Well, no luck, the exe from the 1.2.2 tarball works for me:
$ ../../rel/subversion-1.2.2/Release/subversion/clients/cmdline/svn.exe lock foo --username jrandom
Authentication realm: <http://localhost:80> Subversion Testing
Password for 'jrandom': *********
svn: Lock request failed: 405 Method Not Allowed (http://localhost)
$ wget --http-user=jrandom --http-passwd=rayjandom -O - http://localhost/test-dav/
--20:51:25-- http://localhost/test-dav/
=> `-'
Resolving localhost... 127.0.0.1
Connecting to localhost[127.0.0.1]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 251 [text/html]
<html><head><title>Revision 1: /</title></head>
<body>
<h2>Revision 1: /</h2>
<ul>
<li><a href="foo">foo</a></li>
</ul>
<hr noshade><em>Powered by <a href="http://subversion.tigris.org/">Subversion</a> version 1.1.1 (r11581).</em>
So it seems that the bug is fixed in 1.2.2, too.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 02:09:17 PM:
>
>
>
>>Mark Phippard wrote:
>>
>>
>>
>>>No one has commented on the issue that Stefan King raised. It looks
>>>simple enough to test and if I recall the problem is not specific to
>>>Windows so it could be verified anywhere:
>>>
>>>
>>>
>>>
>>I can't reproduce this, using a stock 1.2.0 client against a 1.1.4
>>mod_dav_svn, both running on Windows:
>>
>>
>
>This is specifically a bug in 1.2.1. It is supposed to be one of the
>things fixed in 1.2.2 which is why Stefan was reporting that he still saw
>the problem. Perhaps he did something wrong in his build, but testing
>with the 1.2.2 client is what needs to be done.
>
>
Ah, I misunderstood. I'm building the 1.2.2 sources now (to sign the
tarball), and will test with that. I agree this should be fixed in 1.2.2
if it's fixed on trunk.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Mark Phippard <Ma...@softlanding.com>.
Branko Čibej <br...@xbc.nu> wrote on 08/11/2005 02:09:17 PM:
> Mark Phippard wrote:
>
> >No one has commented on the issue that Stefan King raised. It looks
> >simple enough to test and if I recall the problem is not specific to
> >Windows so it could be verified anywhere:
> >
> >
> I can't reproduce this, using a stock 1.2.0 client against a 1.1.4
> mod_dav_svn, both running on Windows:
This is specifically a bug in 1.2.1. It is supposed to be one of the
things fixed in 1.2.2 which is why Stefan was reporting that he still saw
the problem. Perhaps he did something wrong in his build, but testing
with the 1.2.2 client is what needs to be done.
Since you all have signed the tarball, presumably you had a built 1.2.2
client handy to test with. I should have just done so myself, but I got
stuck doing something else and was waiting for the tag to be added to I
could just pull from the repository, since that is how my current build
environment was setup.
To test, just use the 1.2.2 client against tigris.org to lock a file. Make
sure credentials are not already cached.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>No one has commented on the issue that Stefan King raised. It looks
>simple enough to test and if I recall the problem is not specific to
>Windows so it could be verified anywhere:
>
>
I can't reproduce this, using a stock 1.2.0 client against a 1.1.4
mod_dav_svn, both running on Windows:
$ svn --version
svn, version 1.2.0 (r14790)
compiled May 22 2005, 22:40:26
...
$ svn ls -v http://localhost/test-dav/ --username jrandom --password rayjandom --no-auth-cache
1 jrandom 0 Aug 11 19:47 foo
$ svn info .
Path: .
URL: http://localhost/test-dav
Repository UUID: 5c1f80b2-a5c0-8f4c-996e-a8de038e9e5a
Revision: 0
Node Kind: directory
Schedule: normal
Last Changed Rev: 0
Last Changed Date: 2005-08-11 19:40:48 +0200 (Thu, 11 Aug 2005)
$ svn lock foo --username jrandom
Authentication realm: <http://localhost:80> Subversion Testing
Password for 'jrandom': *********
svn: Lock request failed: 405 Method Not Allowed (http://localhost)
So I tried with the current trunk (slightly instrumented in
libsvn_ra_dav/util.c, to print the raw Neon error and the converted
error); again, no luck:
$ ../../repos/svn-trunk/Release/subversion/clients/cmdline/svn.exe --version
svn, version 1.3.0 (dev build)
compiled Aug 11 2005, 19:54:39
...
$ ../../repos/svn-trunk/Release/subversion/clients/cmdline/svn.exe lock foo --username jrandom
Authentication realm: <http://localhost:80> Subversion Testing
Password for 'jrandom': *********
NEON_ERR 1 405 Method Not Allowed
SVN_ERR 175002 Lock request failed: 405 Method Not Allowed (http://localhost)
svn: Lock request failed: 405 Method Not Allowed (http://localhost)
And yes, I verified that trunk writes the auth info into the cache in
this case.
O.K., so I see that tortoisesvn.tigris.org is a 1.1.1 server; trying
with that... remember to delete the auth cache... no luck. Same as
before, no crash, auth info gets stored even though the lock request
itself fails.
So, whatever it is, it's either fixed on trunk, or the repro isn't complete.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Mark Phippard <Ma...@softlanding.com>.
No one has commented on the issue that Stefan King raised. It looks
simple enough to test and if I recall the problem is not specific to
Windows so it could be verified anywhere:
Just built the windows svn.exe from the 1.2.x branch (rev 15665).
The crash I reported before still happens:
svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/API test
cd test
svn lock Doxyfile
now I'm asked three times for username/password, then svn.exe crashes.
My guess is that svn_ra_dav__maybe_store_auth_info_after_result() checks
for SVN_ERR_RA_NOT_AUTHORIZED to avoid the crash, but since locking
isn't supported on pre 1.2 servers the returned error is something else
(not implemented). Then that check fails and the function tries to store
the auth data which isn't available.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 10, 2005, at 4:07 PM, Justin Erenkrantz wrote:
> --On August 10, 2005 12:18:14 PM -0700 Ben Reser <be...@reser.org>
> wrote:
>
>
>> 1.2.2 tarballs are up for testing. 1.2.2 was cut from r15671 on the
>> 1.2.x branch.
>>
>> Committers: please test, vote, and send your sigs!
>>
>
> Passes make check on Mac OS X 10.4.2. -- justin
>
Passes 'make check' on all 6 combinations on Windows:
subversion-1.2.2.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQBC+1/nU0gaaOxrUVYRAlP0AJ9Bb5WUFjk/IXSzBw+DYlFESVzyBwCfT4NK
sb8s0s1MLM2vJ6Ky7TawcBg=
=eoeX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 10, 2005 12:18:14 PM -0700 Ben Reser <be...@reser.org> wrote:
> 1.2.2 tarballs are up for testing. 1.2.2 was cut from r15671 on the
> 1.2.x branch.
>
> Committers: please test, vote, and send your sigs!
Passes make check on Mac OS X 10.4.2. -- justin
subversion-1.2.2.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iD8DBQBC+mtxFqlkleIiZ5URAhloAKCncjw6wR/MRGXagPatoWyjyWteXACfRIER
nyolyVA13TjlgCnWVkMwWwk=
=LeIV
-----END PGP SIGNATURE-----
subversion-1.2.2.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iD8DBQBC+muBFqlkleIiZ5URAiHcAKCqiSkuw1mt0bPgjZ+BTylaSGeWRwCgvZU9
+eMLhJUTJ107nDgiSQD2pKk=
=QTEF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: OT: Re: svn 1.2.2 tarballs are up for testing/voting
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> --On August 10, 2005 3:57:16 PM -0600 Jani Averbach <ja...@jaa.iki.fi> wrote:
> > Peter, are you the person to blame that Jim Blandy knows how to
> > pronounce Subversion with Swedish accent? The whole page was almost
> > too much, but the last one, it brought me really close to the edge.
>
> You can't tease us like that. =) URLs please. -- justin
http://subversion.tigris.org/faq.html#pronounce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: OT: Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 10, 2005 3:57:16 PM -0600 Jani Averbach <ja...@jaa.iki.fi> wrote:
> Peter, are you the person to blame that Jim Blandy knows how to
> pronounce Subversion with Swedish accent? The whole page was almost
> too much, but the last one, it brought me really close to the edge.
You can't tease us like that. =) URLs please. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Really OT: Swedish accent? (was: Re: OT: Re: svn 1.2.2 tarballs are up for testing/voting)
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> On Wed, 10 Aug 2005, Jani Averbach wrote:
>
> > On 2005-08-10 22:48+0200, Peter N. Lundblad wrote:
>
> > Peter, are you the person to blame that Jim Blandy knows how to
> > pronounce Subversion with Swedish accent? The whole page was almost
> > too much, but the last one, it brought me really close to the edge.
> >
> > =)
> >
> Haha, blame or claim? Anyway, don't blame me for that "Swedish accent":-)
> I think I'll have to produce some audio file to show the Americans how
> nice the Swedish accent really is... :-)
Here's your chance, bigshot:
http://svn.collab.net/repos/svn-committers/trunk/sounds/
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Really OT: Swedish accent? (was: Re: OT: Re: svn 1.2.2 tarballs are
up for testing/voting)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 10 Aug 2005, Jani Averbach wrote:
> On 2005-08-10 22:48+0200, Peter N. Lundblad wrote:
> Peter, are you the person to blame that Jim Blandy knows how to
> pronounce Subversion with Swedish accent? The whole page was almost
> too much, but the last one, it brought me really close to the edge.
>
> =)
>
Haha, blame or claim? Anyway, don't blame me for that "Swedish accent":-)
I think I'll have to produce some audio file to show the Americans how
nice the Swedish accent really is... :-)
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
OT: Re: svn 1.2.2 tarballs are up for testing/voting
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-08-10 22:48+0200, Peter N. Lundblad wrote:
> On Wed, 10 Aug 2005, Lieven Govaerts wrote:
>
> > I'm sure this is only a question of finding the time, I'm willing
> > to sponsor some good Belgian beer if needed :))
> >
> Wait! I should learn JavaHL in a hurry then:-) Not sure whether the
> Swedish laws allow private import of beer, though:-(
I think you might be on the sunny side, because both of you are part
of EU. Skool and Kippis!
Peter, are you the person to blame that Jim Blandy knows how to
pronounce Subversion with Swedish accent? The whole page was almost
too much, but the last one, it brought me really close to the edge.
=)
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn 1.2.2 tarballs are up for testing/voting
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 10 Aug 2005, Lieven Govaerts wrote:
> Just a question from a user:
>
> Is anyone of the JavaHL committers willing to test my simple patch I
> submitted
> last week for the 'logentry with NULL date crashes the JVM' problem? and
> commit
> that one, or a better patch?
>
Patrick Mayweg said in a private response that he'd try to have a look
during the weekend. It missed 1.2.2, sadly.
> I'm sure this is only a question of finding the time, I'm willing to sponsor
> some
> good Belgian beer if needed :))
>
Wait! I should learn JavaHL in a hurry then:-) Not sure whether the
Swedish laws allow private import of beer, though:-(
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn 1.2.2 tarballs are up for testing/voting
Posted by Lieven Govaerts <lg...@mobsol.be>.
Just a question from a user:
Is anyone of the JavaHL committers willing to test my simple patch I
submitted
last week for the 'logentry with NULL date crashes the JVM' problem? and
commit
that one, or a better patch?
I'm sure this is only a question of finding the time, I'm willing to sponsor
some
good Belgian beer if needed :))
Thanks anyway,
Lieven.
-----Original Message-----
From: Ben Reser [mailto:ben@reser.org]
Sent: woensdag 10 augustus 2005 21:18
To: dev@subversion.tigris.org
Subject: svn 1.2.2 tarballs are up for testing/voting
1.2.2 tarballs are up for testing. 1.2.2 was cut from r15671 on the 1.2.x
branch.
Committers: please test, vote, and send your sigs!
Non-committers: please test anyway. :-)
Hopefully we'll see a final 1.2.2 release in the next couple of days.
Tarballs are up at http://fornix.brain.org/subversion/
-rw-rw-r-- 1 svnrm svnrm 7235030 Aug 10 15:06 subversion-1.2.2.tar.bz2
-rw-rw-r-- 1 svnrm svnrm 8873107 Aug 10 15:06 subversion-1.2.2.tar.gz
-rw-rw-r-- 1 svnrm svnrm 11718604 Aug 10 15:11 subversion-1.2.2.zip
md5sums:
1e52c75277a17909ab606d992587975c subversion-1.2.2.tar.bz2
a7615c4db9f5e23d643f77ecd123cc7e subversion-1.2.2.tar.gz
2fd825e3a5104a5e5dcb0654fd86d931 subversion-1.2.2.zip
sha1sums:
a45ec89444086e7f8ca429ade7ee1ea3526db671 subversion-1.2.2.tar.bz2
84ba9fd2935ed4c5d2c095a3213191fbb5c52c6b subversion-1.2.2.tar.gz
484a7327aa71e485b19b251d98b14cea294434cf subversion-1.2.2.zip
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.5/67 - Release Date: 9/08/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.5/67 - Release Date: 9/08/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org