Re: RE: Proxy authentication with Negotiate uses wrong host
On Wed, 2011-08-24 at 07:42 -0400, 1983-01...@gmx.net wrote: > Are you refering to sole Kerberos or are you just concerned about > transport encryption? Your statement somewhat irritates me. > Given that the HTTP traffic cannot be securely wrapped into the GSS > content and nor the SASL QOP can be set (like for LDAP), I would > neglect that and still say TLS is not of your concern but of mine or > the users in general. Any authentication-only mechanism used over an insecure channel is vulnerable to MITM attacks which preserve the authentication and change the data. Of course, this applies to HTTP basic and digest over raw HTTP just as much as it does to negotiate, so perhaps it doesn't make sense to restrict negotiate auth to HTTPS only on this basis alone. A further concern with HTTP negotiate is that it is scoped to the TCP connection and not to a single HTTP request. Ignorant proxies may combine TCP connections for multiple users' requests and inadvertently authenticate one users' requests with anothers' credentials. I may be wrong, but I believe this is the concern which leads implementations to restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not mitigate this concern at all. If there are other vulnerabilities in NTLM which don't presuppose an MITM attack, perhaps I'm wrong.
Re: assert triggered in update_editor.c
On Wed, Aug 24, 2011 at 5:01 PM, Stefan Sperling wrote: > On Wed, Aug 24, 2011 at 03:12:04PM +0200, Erik Faye-Lund wrote: >> In file >> 'D:\Development\SVN\Releases\TortoiseSVN-1.7-beta2\ext\subversion\subversion\libsvn_wc\update_editor.c' >> line 1582: assertion failed (action == svn_wc_conflict_action_edit || action >> == svn_wc_conflict_action_delete || action == >> svn_wc_conflict_action_replace) >> --- >> OK >> --- >> ---8<--- >> >> I don't know the code-base, but my knee-jerk instinct was that I did >> have local modifications in some of the files; luckily these were pure >> throw-away things. So after a clean-up and revert I updated again, and >> everything seems to be in order again. > > This is definitely something related to tree conflicts. > You must have had a locally edited, deleted, or replaced node. > The incoming change was something other than an edit, delete, > or replace. But shouldn't that have been solved by a revert in that case? Because it still triggers when I revert and re-update here... > If you can still manage to produce a reproduction recipe based on this > information please share it! Thanks. Unfortunately, the repo is proprietary, and I don't know how I can re-create the issue outside of my corporate setup...
Re: RE: Proxy authentication with Negotiate uses wrong host
> On Wed, 2011-08-24 at 07:42 -0400, 1983-01...@gmx.net wrote: > > Are you refering to sole Kerberos or are you just concerned about > > transport encryption? Your statement somewhat irritates me. > > Given that the HTTP traffic cannot be securely wrapped into the GSS > > content and nor the SASL QOP can be set (like for LDAP), I would > > neglect that and still say TLS is not of your concern but of mine or > > the users in general. > > Any authentication-only mechanism used over an insecure channel is > vulnerable to MITM attacks which preserve the authentication and change > the data. Of course, this applies to HTTP basic and digest over raw > HTTP just as much as it does to negotiate, so perhaps it doesn't make > sense to restrict negotiate auth to HTTPS only on this basis alone. > > A further concern with HTTP negotiate is that it is scoped to the TCP > connection and not to a single HTTP request. Ignorant proxies may > combine TCP connections for multiple users' requests and inadvertently > authenticate one users' requests with anothers' credentials. I may be > wrong, but I believe this is the concern which leads implementations to > restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not > mitigate this concern at all. If there are other vulnerabilities in > NTLM which don't presuppose an MITM attack, perhaps I'm wrong. Greg, thanks for the insight. I will file a bug that the sole negotiate/kerberos and SSL restriction should be removed because it is not enforced on basic and digest either. Mike -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
403 forbidden when copying path with no permissions
I'm having issues doing an svn copy on the trunk of my project because I don't have read permissions to a directory further down the tree. My example authz: [test:/] myuser=rw [test:/proj1/trunk/dir1/dir1.2] myuser= The /proj1/trunk/dir1/dir1.2 was deleted a couple of revisions ago, so the project at HEAD looks like this: branches/ tags/ trunk/ trunk/dir1/ trunk/dir1/dir1.1/ When I try to copy trunk I get a 403 forbidden: svn copy https://svn/svn/test/proj1/trunk https://svn/svn/test/proj1/branches/branch1 -m "test" svn: access to '/svn/test/!svn/bc/6/proj1/trunk' forbidden However if I give myself read permissions on /proj1/trunk/dir1/dir1.2 I can do the copy. Why is svn trying to access the directory if it doesn't exist at HEAD? Any help on this would be great. Thanks *bypass*
Re: assert triggered in update_editor.c
On Thu, Aug 25, 2011 at 11:51:33AM +0200, Erik Faye-Lund wrote: > On Wed, Aug 24, 2011 at 5:01 PM, Stefan Sperling wrote: > > On Wed, Aug 24, 2011 at 03:12:04PM +0200, Erik Faye-Lund wrote: > >> In file > >> 'D:\Development\SVN\Releases\TortoiseSVN-1.7-beta2\ext\subversion\subversion\libsvn_wc\update_editor.c' > >> line 1582: assertion failed (action == svn_wc_conflict_action_edit || > >> action > >> == svn_wc_conflict_action_delete || action == > >> svn_wc_conflict_action_replace) > >> --- > >> OK > >> --- > >> ---8<--- > >> > >> I don't know the code-base, but my knee-jerk instinct was that I did > >> have local modifications in some of the files; luckily these were pure > >> throw-away things. So after a clean-up and revert I updated again, and > >> everything seems to be in order again. > > > > This is definitely something related to tree conflicts. > > You must have had a locally edited, deleted, or replaced node. > > The incoming change was something other than an edit, delete, > > or replace. > > But shouldn't that have been solved by a revert in that case? Because > it still triggers when I revert and re-update here... The assertion means that the client thinks the server is sending nonsense. This might be a bug where the client makes an invalid assumption about compatibility of the local working copy state with incoming changes. Does it also happen in a separate, fresh checkout of the revision the containing directory of this file (or the file itself) is at? Does it also happen with the command line client (if you have one available)? > > If you can still manage to produce a reproduction recipe based on this > > information please share it! Thanks. > > Unfortunately, the repo is proprietary, and I don't know how I can > re-create the issue outside of my corporate setup... If you can share the wc.db file from your working copy privately you can send it to me off-list. There is no file content in wc.db, only path names and svn: properties. I won't share any of the data with anyone.
Re: assert triggered in update_editor.c
Stefan Sperling wrote on Thu, Aug 25, 2011 at 18:02:10 +0200: > On Thu, Aug 25, 2011 at 11:51:33AM +0200, Erik Faye-Lund wrote: > > On Wed, Aug 24, 2011 at 5:01 PM, Stefan Sperling wrote: > > > On Wed, Aug 24, 2011 at 03:12:04PM +0200, Erik Faye-Lund wrote: > > >> In file > > >> 'D:\Development\SVN\Releases\TortoiseSVN-1.7-beta2\ext\subversion\subversion\libsvn_wc\update_editor.c' > > >> line 1582: assertion failed (action == svn_wc_conflict_action_edit || > > >> action > > >> == svn_wc_conflict_action_delete || action == > > >> svn_wc_conflict_action_replace) > > >> --- > > >> OK > > >> --- > > >> ---8<--- > > >> > > >> I don't know the code-base, but my knee-jerk instinct was that I did > > >> have local modifications in some of the files; luckily these were pure > > >> throw-away things. So after a clean-up and revert I updated again, and > > >> everything seems to be in order again. > > > > > > This is definitely something related to tree conflicts. > > > You must have had a locally edited, deleted, or replaced node. > > > The incoming change was something other than an edit, delete, > > > or replace. > > > > But shouldn't that have been solved by a revert in that case? Because > > it still triggers when I revert and re-update here... > > The assertion means that the client thinks the server is sending > nonsense. Is that so? The client isn't supposed to assert on bad server behaviour.
