RE: Cope with IPv6
Dear Ivan Zhakov, Thank you very much. > -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: Tuesday, August 13, 2013 8:52 PM > To: Okabayashi, Hirotsugu > Cc: Daniel Shahaf; users@subversion.apache.org > Subject: Re: Cope with IPv6 > > On Tue, Aug 13, 2013 at 12:52 PM, Okabayashi, Hirotsugu > wrote: > > Dear Daniel, > > > > Thank you for your reply and I'm sorry to be late. > >> > > -Only with IPv6, the Operating system handle the authentication. > >> > > >> > What does this mean? > > Sorry, let me explain about that in detail. > > With IPv4, TSVN displays TSVN's authentication window. > > With IPv6, however, TSVN displays Windows's authentication > > window(Windows Security Window) instead of TSVN's authentication window. > TSVN displays Windows's authentication window when it tries to get list > of repositories using Windows API, not Subversion libraries. > > > > > -- > Ivan Zhakov > CTO | VisualSVN | http://www.visualsvn.com
Re: Issue 4039
Thanks for responding I'll be waiting 2013/8/18 Johan Corveleyn > On Fri, Aug 16, 2013 at 8:31 PM, Angelo Tavares > wrote: > > > > Good Morning > > > > You have a preview release of this fix, or if it will be developed? > > > > http://subversion.tigris.org/issues/show_bug.cgi?id=4039 > > The issue is: "Add support for windows substed-drives" > > The last comment in the issue tracker says: "Reading symlinks on > Windows Vista and later implemented in r1501251 on trunk. So probably > this issue also fixed." > > So it sounds like it's not fixed in 1.8, but possibly fixed in trunk > (i.e. the future 1.9 version). > > I'm not sure if this bugfix is at all backportable to 1.8, or if > you'll have to wait for 1.9. Maybe someone else can comment > (otherwise: go ahead and ask the "can it be backported" question in > the issue tracker). > > (@Ivan: maybe the issue needs to be marked "fixed" in the issue > tracker, if your last comment is correct). > > -- > Johan >
Is this for the dev list?, was: svnserve: could not find auxprop plugin, was searching for 'ldap' (1.8.1, linux, from source)
Shall I write my question (below) to the dev list?
(It seems to be a question about compilation currently)
Or can I prepare / rewrite something to make it more likely to get an answer
here?
-Ursprüngliche Nachricht-
Von: Klaus Thorn [mailto:klaus.th...@noumenastudios.com]
Gesendet: 14 August 2013 12:21
An: users@subversion.apache.org
Betreff: svnserve: could not find auxprop plugin, was searching for 'ldap'
(1.8.1, linux, from source)
The error:
svnserve: could not find auxprop plugin, was searching for 'ldap'
is appearing in /var/log/auth.log
whenever I try to log in. It always fails.
Test setup: I am opening Tortoise-SVN repo-browser on a Windows client machine
with a svn:// URL pointing to my new subversion server and try to log in.
The login does not work, the login dialog gets displayed again.
Instead I expect svnserve to use the ldap lib and saslauthd to auth against our
local Windows domain's Active Directory.
Which perfectly works on my older subversion server running Ubuntu 11.04 with
ubuntu's binary SVN packages.
How do I get that to work on the new server, too?
__Why does it not work on the ("new") Ubuntu 12.04 server with Subversion 1.8.1
built from source?
I think I ruled out a lot of usual suspects:
- Saslauthd is not a suspect, because by using testsaslauthd on the same 12.04
server, I AM able to auth against our Active Directory. Also, The error (above)
says "svnserve..." not "sasl...".
- All the configuration files are identical to my working installation on my
old Ubuntu 11.04 server, so I have no reason to doubt them.
Currently, in my view, only the svnserve binary is left as the main suspect.
But other opinions are welcome (but not: "use apache instead of svnserve" :-).
On that "svnserve is the problem" road I found my only current hint to a cause:
The working svnserve on the ("old") 11.04 server has the following linking (as
seen with ldd):
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2
I guess that I did not manage to get that linking [or library] included in my
source build.
(and by the way: Ubuntu 12.04 did not, either, because the svnserve binary of
Ubuntu 12.04 is missing this linking, too, and does not work for me.)
__Details (on the not working setup):
Subversion 1.8.1 is built from source, on Ubuntu 12.04 64bit, with sqlite
amalgamation.
uname -a @12.04 server:
Linux zeus 3.2.0-34-generic #53-Ubuntu SMP Thu Nov 15 10:48:16 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
Ubuntu Packages installed with "ldap" in their name:
Installed: ldap-utils 2.4.28-1.1ubuntu4.3
Installed: libaprutil1-ldap 1.3.12+dfsg-3
Installed: libldap-2.4-22.4.28-1.1ubuntu4.3
Installed: libldap2-dev 2.4.28-1.1ubuntu4.3
Installed: libsasl2-modules-ldap2.1.25.dfsg1-3ubuntu0.1
Config files (as I said, I have no reason to doubt them):
/etc/sasl2/svn.conf
pwcheck_method: saslauthd
log_level: 5
auxprop_plugin: ldap
allow_plaintext: true
mech_list: PLAIN
ldapdb_mech: PLAIN
.../conf/svnserve.conf
[general]
anon-access = none
auth-access = write
authz-db = permissions
realm = noumena.de
[sasl]
use-sasl = true
min-encryption = 0
max-encryption = 0
/etc/default/saslauthd
START=yes
MECHANISMS="ldap"
MECH_OPTIONS=""
OPTIONS="-c -m /var/run/saslauthd"
/etc/saslauthd.conf
ldap_servers: ldap://**SERVERNAME**.noumena.de
ldap_default_domain: noumena.de
ldap_search_base: DC=noumena,DC=de
ldap_bind_dn: CN=**username**,CN=Users,DC=noumena,DC=de
ldap_bind_pw: **PW**
ldap_password: **PW**
ldap_mech: PLAIN
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%U
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768
__Details on the working ("old") setup:
Although I do not want to make this an Ubuntu discussion, (because I already
tried and failed to get support from the Ubuntu community and because building
from source gives me access to SVN 1.8; in contrast to 1.6!
) I nevertheless include more details just in case they might somehow help:
uname -a @11.04 server: (the old working setup) Linux rogue 2.6.38-8-server
#42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
SVN 1.6.12dfsg-4ubuntu2.1
Config: as above with the not working setup.
There are a lot more libraries that are linked into svnserve of Ubuntu 11.04
(binary package SVN 1.6.12dfsg-4ubuntu2.1) but not into 12.04 (binary package
SVN 1.6.17dfsg-3ubuntu3):
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x7f22fb596000)
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x7f22fb387000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f22f9ed7000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
(0x7f22f9ca2000)
libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26
(0x7f22f9a0)
libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x7f22f9786000)
libkrb5.so.
Re: Subversion 1.8 httpd.exe taking 100% CPU
> We just upgraded subversion from 1.7 to 1.8 and noticed that the process httpd.exe takes 100% and maxes the box and we have to keep killing the httpd.exe, are you aware of this problem? > > > * What's your environment (svn client / server / Apache HTTP Server > version)? > > We using TortoiseSVN 1.8 / CollabNet Edge / Apache HTTP Server version > 2.4.4 > > * What exactly do you do when the httpd.exe starts to consume 100% CPU > time? > > We don’t know exactly what causes it because nothing is written to any > logs as far we can see, however once we kill the httpd.exe then it’s find > for another couple of hours. > > > Was there ever a solution/progress on this? I am having the exact same issue, with the same setup. Also usful to know we're using LDAP authentication against our AD domain. Subversion edge is running on Windows Server 2008 R2 x64.
RE: Subversion 1.8 httpd.exe taking 100% CPU
I did not find a solution however I wrote an monitor application that checks if the httpd.exe process hits 100%, if so I KILL the process and CollabNet then restarts another instance. From: valentijnschol...@gmail.com [mailto:valentijnschol...@gmail.com] Sent: 19 August 2013 16:37 To: subversion_us...@googlegroups.com Cc: Pavel Lyalyakin; users@subversion.apache.org; Dinesh Hirani Subject: Re: Subversion 1.8 httpd.exe taking 100% CPU > We just upgraded subversion from 1.7 to 1.8 and noticed that the process > httpd.exe takes 100% and maxes the box and we have to keep killing the > httpd.exe, are you aware of this problem? * What's your environment (svn client / server / Apache HTTP Server version)? We using TortoiseSVN 1.8 / CollabNet Edge / Apache HTTP Server version 2.4.4 * What exactly do you do when the httpd.exe starts to consume 100% CPU time? We don’t know exactly what causes it because nothing is written to any logs as far we can see, however once we kill the httpd.exe then it’s find for another couple of hours. Was there ever a solution/progress on this? I am having the exact same issue, with the same setup. Also usful to know we're using LDAP authentication against our AD domain. Subversion edge is running on Windows Server 2008 R2 x64. The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access by any other person to this e-mail is not authorized. If you are not the intended recipient, please delete this e-mail. Any disclosure of this e-mail or of the parties to it and any copying or distribution of it is prohibited (and may be unlawful). The information expressed herein may be changed at any time without notice or obligation to update. We do not represent that this message is virus-free, complete or accurate and it should not be relied upon as such. Electronic communications may be monitored for operational and business purposes to the extent permitted by applicable law. This email does not constitute legal or tax advice, and the information contained in this communication should not be regarded as such. Decura IM LLP is authorised and regulated by the Financial Conduct Authority. Registered office address: 11-12 St James’s Square, London SW1Y 4LB. Registered in England and Wales: OC375344 Decura LLP is authorised and regulated by the Financial Conduct Authority. Registered office address: 11-12 St James’s Square, London SW1Y 4LB. Registered in England and Wales: OC377231
server config
Hi all, I'm new to SVN server configuration and find myself setting up a CentOS 6.4 server with svn version 1.6.1, following the red-bean book. I'm having difficulty with authorization &/or authentication: my repo appears to be accessible by anyone in spite of requiring "valid-user" and specifying digest authentication. I believe this because 1) I can download a full working copy of the repo to a 3rd-party logged into a foreign computer, and 2) I have dozens of entries in apache's logfiles, like these from this morning, *prior* to any known/legitimate access to my repos today: svn_logfile: [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity access_log 93.174.93.213 - - [19/Aug/2013:07:23:50 +] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 319 "-" "ZmEu" error_log [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not exist: /var/www/html/MyAdmin This doesn't look good at all. My Location directive follows below. The /etc/svn-auth.htdigest exists and appears to be valid. My goal is to setup the repo, serve it via Apache, provide access to only a small number of people that I approve, use cmd-line svn and do so securely. This is my first brush with Apache, OpenSSL, and general server config. Thanks in advance for your suggestions! BTW, I'm not subscribed and would appreciate being cc'd on any replies. Scott DAV svn SVNParentPath /var/svn # Authentication: Digest AuthName "Subversion repository" AuthType Digest AuthUserFile /etc/svn-auth.htdigest # Authorization: Authenticated users only Require valid-user
Re: server config
On 8/19/2013 9:07 AM, Scott Frankel wrote: Hi all, I'm new to SVN server configuration and find myself setting up a CentOS 6.4 server with svn version 1.6.1, following the red-bean book. I'm having difficulty with authorization &/or authentication: my repo appears to be accessible by anyone in spite of requiring "valid-user" and specifying digest authentication. I believe this because 1) I can download a full working copy of the repo to a 3rd-party logged into a foreign computer, and 2) I have dozens of entries in apache's logfiles, like these from this morning, *prior* to any known/legitimate access to my repos today: Step 1: Take the real repo offline until you get the security problems resolved. Every IP address on the Internet is scanned every single day, and your repo is vulnerable right now. Step 2: Run experiments with a dummy repo to resolve the security problems. Don't ever run security experiments with production data. Put production data online only after you know that all security problems have been resolved. svn_logfile: [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity This does not look good at all. It's quite possible that someone else has downloaded your repository. The access_log file may tell you the IP address from which the request was made; with luck it's the one you were experimenting with and the time stamp matches your access. access_log 93.174.93.213 - - [19/Aug/2013:07:23:50 +] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 319 "-" "ZmEu" If you watch access_log over time, as I do, you will see these sorts of probes constantly. Too many to list, they are meant to check for known vulnerabilities in older versions of Apache or tools installed (SQL administration, PHP administration, etc.). These will never go away. Get used to them. They should all fail; if not then you have other security problems to fix. error_log [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not exist: /var/www/html/MyAdmin This doesn't look good at all. My Location directive follows below. The /etc/svn-auth.htdigest exists and appears to be valid. My goal is to setup the repo, serve it via Apache, provide access to only a small number of people that I approve, use cmd-line svn and do so securely. These are standard goals. This is my first brush with Apache, OpenSSL, and general server config. Thanks in advance for your suggestions! BTW, I'm not subscribed and would appreciate being cc'd on any replies. Scott DAV svn SVNParentPath /var/svn # Authentication: Digest AuthName "Subversion repository" AuthType Digest AuthUserFile /etc/svn-auth.htdigest # Authorization: Authenticated users only Require valid-user How many repositories do you have? You shouldn't use SVNParentPath if you have only one repository; use SVNPath. I don't know if that is the direct cause of your problem, but you should fix it. You can also try working with AuthType Basic, creating passwords with /usr/sbin/htpasswd, until you figure things out. I have more experience with that than AuthType Digest, so I can't help you there. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: server config
Being that you will be using WebDAV, I'd recommend you look at the AuthzSVNAccessFile directive and control the access you want that way. Here is what mine looks like: DAV svn SVNPath /var/svn AuthzSVNAccessFile /var/svn/svnaccess.conf Require Valid-User AuthType Basic AuthName "Code Repository" AuthUserFile /var/svn/passwd HTH. YMMV. Regards, Dana On Mon, Aug 19, 2013 at 9:07 AM, Scott Frankel wrote: > > Hi all, > > I'm new to SVN server configuration and find myself setting up a CentOS > 6.4 server with svn version 1.6.1, following the red-bean book. > > I'm having difficulty with authorization &/or authentication: my repo > appears to be accessible by anyone in spite of requiring "valid-user" and > specifying digest authentication. I believe this because 1) I can download > a full working copy of the repo to a 3rd-party logged into a foreign > computer, and 2) I have dozens of entries in apache's logfiles, like these > from this morning, *prior* to any known/legitimate access to my repos today: > > svn_logfile: > [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity > > access_log > 93.174.93.213 - - [19/Aug/2013:07:23:50 +] "GET > /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 319 "-" "ZmEu" > > error_log > [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not > exist: /var/www/html/MyAdmin > > > This doesn't look good at all. My Location directive follows below. The > /etc/svn-auth.htdigest exists and appears to be valid. My goal is to setup > the repo, serve it via Apache, provide access to only a small number of > people that I approve, use cmd-line svn and do so securely. > > This is my first brush with Apache, OpenSSL, and general server config. > Thanks in advance for your suggestions! BTW, I'm not subscribed and would > appreciate being cc'd on any replies. > Scott > > > > > DAV svn > SVNParentPath /var/svn > > # Authentication: Digest > AuthName "Subversion repository" > AuthType Digest > AuthUserFile /etc/svn-auth.htdigest > > # Authorization: Authenticated users only > Require valid-user > > > > > -- Regards, Dana Epp Microsoft Security MVP
Switching
Hello, I want to thank all who have been helpful. I have gotten my test project to merge branches successfully. Now I am trying it on our production code and wish to make sure I am not making any mistakes. I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory. I have created two branches for two new features. One feature extends an existing library. The other feature adds a new library as well as extending an existing one. When I switch I create a conflict because the directory exists in one branch and not the other: local unversioned, incoming add upon switch This may or may not be what is supposed to happen, that would be the first thing I would like to know. How to fix it would be the second thing that I would like to know. According to the help of the resolve command says: So I tried svn resolve -accept working LibraryDirectory but I believe that was a mistake because then the directory was marked "Delete" which is not what I wanted. Does anyone know what is the proper response? I did not want to lose the library from the working copy so I switched back to the other branch and then switch back. Now it says: local delete, incoming delete upon switch It seems I did something wrong. My next step would be to add the library back, but that may not be the best response. Any suggestions? Thanks JM
Re: checkout / update problem: svn: Malformed XML: not well-formed (invalid token) at line ...
Issue 2730 needs to be re-visited!!! (http://subversion.tigris.org/issues/show_bug.cgi?id=2730) I relocated an SVN repository, and shortly thereafter began seeing the "Issue 2730" problem. What a "PAIN"... Every time I do an "svn commit," the log-file inserts the same non-ASCII characters into the user-name value along with a valid user-name. I have to do an "svnadmin setrevprop" to fix the incoming version's "svn:author" property, and edit the update's log-file to remove the non-ASCII characters. Most lately, something has become so messed-up, that SVN adds a file, then breaks because of the the mal-formed XML problem, and then refuses to accept the file it had just added. Even the --force option does not help... I cannot break out of this cleanup/update cycle, now, no matter what I try. -- View this message in context: http://subversion.1072662.n5.nabble.com/checkout-update-problem-svn-Malformed-XML-not-well-formed-invalid-token-at-line-tp121894p184159.html Sent from the Subversion Users mailing list archive at Nabble.com.
Cannot check out public directory with client 1.8.x without access to repo root
Hello, I'm having an issue with our partially-public SVN repository. The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS. Our repository (let's call it "myrepo") allows public read access (* = r) to myrepo/trunk, but not to myrepo/ (the root). There is also a directory myrepo/trunk/secret to which only specific users have access to. Everything has been working as expected with SVN 1.6 and 1.7 clients: in particular, no username or password is requested when checking out myrepo/trunk. However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check out any directory without supplying the credentials of a user who has access to the repository root. svn co https://our.server.com/svn/myrepo/trunk -> Requires authentication with client 1.8.x but not with 1.6.x or 1.7.x svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1 svn list https://our.server.com/svn/myrepo -> Requires auth, as expected The 1.8.x clients can successfully check out myrepo/trunk if a username and password are given, for a user with access to the repository root. I have so far been unable to reproduce this with a simplified test repository, so any hints as to where to look would be much appreciated. The following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.6.18 (OS X): xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 197 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 479 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/bc/123/trunk HTTP/1.1" 207 718 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 197 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 And the following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows 7): xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 197 xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 97 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/bc/123/trunk HTTP/1.1" 207 781 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 276 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 197 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 97 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/bc/123/trunk HTTP/1.1" 207 341 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 197 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "OPTIONS /svn/myrepo/trunk HTTP/1.1" 200 97 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/trunk HTTP/1.1" 207 704 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND /svn/myrepo/!svn/bln
Re: server config
David Chapman wrote on Mon, Aug 19, 2013 at 09:42:42 -0700: > You shouldn't use SVNParentPath if you have only one repository; use > SVNPath. I don't know if that is the direct cause of your problem, > but you should fix it. I disagree. I'm not aware of a reason to prefer one over the other.
Re: server config
On 8/19/2013 12:42 PM, David Chapman wrote: How many repositories do you have? You shouldn't use SVNParentPath if you have only one repository; use SVNPath. I don't know if that is the direct cause of your problem, but you should fix it. I suggest planning for multiple repositories from the get-go. Some things in SVN land work better when you dedicate a separate repository to it. We started with one monolithic repository, but have since split that into ~300 smaller repositories.
Re: Cannot check out public directory with client 1.8.x without access to repo root
Mark Tsuchida wrote on Mon, Aug 19, 2013 at 11:19:42 -0700: > svn co https://our.server.com/svn/myrepo/trunk -> Requires > authentication with client 1.8.x but not with 1.6.x or 1.7.x > svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1 > svn list https://our.server.com/svn/myrepo -> Requires auth, as expected > > The 1.8.x clients can successfully check out myrepo/trunk if a > username and password are given, for a user with access to the > repository root. > > I have so far been unable to reproduce this with a simplified test > repository, so any hints as to where to look would be much > appreciated. You could mount your real repository on a test , at a different URI, that uses IP-whitelisting to permit only your workstation, and then fiddle with the settings ( directives, authz file contents, etc.) to see if you can identify the problem. Information that might be relevant includes: - The authz file - The block - Whether 1.7.x reproduces the problem under either serf and neon (did you test with each of them?) - Whether the problem reproduces with 1.6.17 Also, you should upgrade to at least 1.6.17, if not 1.7.11 or 1.8.1, to pick up fixes to security issues. (An upgrade to at least 1.7 could easily fix your problem, too, since it'll enable 1.7+ clients to talk HTTPv2, which will avoid the HTTP-non-v2 compatibility codepath (unless you have 1.6 clients too...).)
Re: server config
Hi all, Thanks for the replies! Please see below for additional comments. On Aug 19, 2013, at 9:42 AM, David Chapman wrote: > On 8/19/2013 9:07 AM, Scott Frankel wrote: >> Hi all, >> >> I'm new to SVN server configuration and find myself setting up a CentOS 6.4 >> server with svn version 1.6.1, following the red-bean book. >> >> I'm having difficulty with authorization &/or authentication: my repo >> appears to be accessible by anyone in spite of requiring "valid-user" and >> specifying digest authentication. I believe this because 1) I can download >> a full working copy of the repo to a 3rd-party logged into a foreign >> computer, and 2) I have dozens of entries in apache's logfiles, like these >> from this morning, *prior* to any known/legitimate access to my repos today: > > Step 1: Take the real repo offline until you get the security problems > resolved. Every IP address on the Internet is scanned every single day, and > your repo is vulnerable right now. > Step 2: Run experiments with a dummy repo to resolve the security problems. > > Don't ever run security experiments with production data. Put production > data online only after you know that all security problems have been resolved. Good points! My repo currently being downloaded by whomever is a testProj with absolutely nothing of value in it. >> svn_logfile: >> [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity > > This does not look good at all. It's quite possible that someone else has > downloaded your repository. The access_log file may tell you the IP address > from which the request was made; with luck it's the one you were > experimenting with and the time stamp matches your access. > >> access_log >> 93.174.93.213 - - [19/Aug/2013:07:23:50 +] "GET >> /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 319 "-" "ZmEu" > > If you watch access_log over time, as I do, you will see these sorts of > probes constantly. Too many to list, they are meant to check for known > vulnerabilities in older versions of Apache or tools installed (SQL > administration, PHP administration, etc.). These will never go away. Get > used to them. They should all fail; if not then you have other security > problems to fix. OK. Getting used to common log entries is important. >> error_log >> [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not >> exist: /var/www/html/MyAdmin >> >> >> This doesn't look good at all. My Location directive follows below. The >> /etc/svn-auth.htdigest exists and appears to be valid. My goal is to setup >> the repo, serve it via Apache, provide access to only a small number of >> people that I approve, use cmd-line svn and do so securely. > > These are standard goals. Good. I mention them in hopes it whittles-down in advance any suggestions you might have. eg: the red-bean book has quite a lot to say about tunneling svnserve, which is not germane to my setup. >> This is my first brush with Apache, OpenSSL, and general server config. >> Thanks in advance for your suggestions! BTW, I'm not subscribed and would >> appreciate being cc'd on any replies. >> Scott >> >> >> >> >> DAV svn >> SVNParentPath /var/svn >> >> # Authentication: Digest >> AuthName "Subversion repository" >> AuthType Digest >> AuthUserFile /etc/svn-auth.htdigest >> >> # Authorization: Authenticated users only >> Require valid-user >> >> >> > > How many repositories do you have? You shouldn't use SVNParentPath if you > have only one repository; use SVNPath. I don't know if that is the direct > cause of your problem, but you should fix it. I chose to use SVNParentPath on purpose. As soon as I have a secure, working server config, I'll be hosting multiple repos. Daniel and Thomas, thanks for your suggestions. > You can also try working with AuthType Basic, creating passwords with > /usr/sbin/htpasswd, until you figure things out. I have more experience with > that than AuthType Digest, so I can't help you there. I'll try that to see what I discover; but ultimately my research so far points to Digest mode being more secure. Thanks for the suggestions! Scott > > -- >David Chapman dcchap...@acm.org >Chapman Consulting -- San Jose, CA >Software Development Done Right. >www.chapman-consulting-sj.com >
Re: Cannot check out public directory with client 1.8.x without access to repo root
On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida wrote: > Hello, > > I'm having an issue with our partially-public SVN repository. > > The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS. > Our repository (let's call it "myrepo") allows public read access (* = > r) to myrepo/trunk, but not to myrepo/ (the root). There is also a > directory myrepo/trunk/secret to which only specific users have access > to. > > Everything has been working as expected with SVN 1.6 and 1.7 clients: > in particular, no username or password is requested when checking out > myrepo/trunk. > > However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check > out any directory without supplying the credentials of a user who has > access to the repository root. > > svn co https://our.server.com/svn/myrepo/trunk -> Requires > authentication with client 1.8.x but not with 1.6.x or 1.7.x > svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1 > svn list https://our.server.com/svn/myrepo -> Requires auth, as expected > > The 1.8.x clients can successfully check out myrepo/trunk if a > username and password are given, for a user with access to the > repository root. > > I have so far been unable to reproduce this with a simplified test > repository, so any hints as to where to look would be much > appreciated. > > The following is the section of ssl_access_log produced by checking > out myrepo/trunk using client 1.6.18 (OS X): > xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "OPTIONS > /svn/myrepo/trunk HTTP/1.1" 200 197 [...] > /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 > xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND > /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 > > And the following is the section of ssl_access_log produced by > checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows > 7): > xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] "OPTIONS > /svn/myrepo/trunk HTTP/1.1" 200 197 [...] > xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND > /svn/myrepo/!svn/bc/123 HTTP/1.1" 401 483 > > It appears that the 1.8.1 client requests /svn/myrepo/!svn/bc/123, to > which access is denied (401), whereas client 1.6.18 only ever requests > /svn/myrepo/!svn/bc/123/trunk, to which access is granted. > Most likely it is some problem with inherited properties feature implemented in Subversion 1.8. @Paul: Do you have any ideas? -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Issue 4039
On Mon, Aug 19, 2013 at 2:04 AM, Johan Corveleyn wrote: > On Fri, Aug 16, 2013 at 8:31 PM, Angelo Tavares wrote: >> >> Good Morning >> >> You have a preview release of this fix, or if it will be developed? >> >> http://subversion.tigris.org/issues/show_bug.cgi?id=4039 > > The issue is: "Add support for windows substed-drives" > > The last comment in the issue tracker says: "Reading symlinks on > Windows Vista and later implemented in r1501251 on trunk. So probably > this issue also fixed." > > So it sounds like it's not fixed in 1.8, but possibly fixed in trunk > (i.e. the future 1.9 version). > > I'm not sure if this bugfix is at all backportable to 1.8, or if > you'll have to wait for 1.9. Maybe someone else can comment > (otherwise: go ahead and ask the "can it be backported" question in > the issue tracker). > > (@Ivan: maybe the issue needs to be marked "fixed" in the issue > tracker, if your last comment is correct). > Johan, Issue 4039 missing details what is not working in users case. There is no reproduction case or something. Bert pointed the most likely users want to create SUBST drive for part of working. This case is not solved by my fix. And most likely never be fixed, so issue should be closed with "WONTFIX" or "BYDESIGN". Angelo: what is not working in your case? -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Issue 4039
My case is creating subst working areas, which is not presented the features of subversion. 2013/8/19 Ivan Zhakov > On Mon, Aug 19, 2013 at 2:04 AM, Johan Corveleyn > wrote: > > On Fri, Aug 16, 2013 at 8:31 PM, Angelo Tavares > wrote: > >> > >> Good Morning > >> > >> You have a preview release of this fix, or if it will be developed? > >> > >> http://subversion.tigris.org/issues/show_bug.cgi?id=4039 > > > > The issue is: "Add support for windows substed-drives" > > > > The last comment in the issue tracker says: "Reading symlinks on > > Windows Vista and later implemented in r1501251 on trunk. So probably > > this issue also fixed." > > > > > So it sounds like it's not fixed in 1.8, but possibly fixed in trunk > > (i.e. the future 1.9 version). > > > > I'm not sure if this bugfix is at all backportable to 1.8, or if > > you'll have to wait for 1.9. Maybe someone else can comment > > (otherwise: go ahead and ask the "can it be backported" question in > > the issue tracker). > > > > (@Ivan: maybe the issue needs to be marked "fixed" in the issue > > tracker, if your last comment is correct). > > > Johan, > > Issue 4039 missing details what is not working in users case. There is > no reproduction case or something. Bert pointed the most likely users > want to create SUBST drive for part of working. This case is not > solved by my fix. And most likely never be fixed, so issue should be > closed with "WONTFIX" or "BYDESIGN". > > Angelo: what is not working in your case? > > > -- > Ivan Zhakov > CTO | VisualSVN | http://www.visualsvn.com >
Re: server config
On 8/19/2013 12:13 PM, Scott Frankel wrote: This is my first brush with Apache, OpenSSL, and general server config. Thanks in advance for your suggestions! BTW, I'm not subscribed and would appreciate being cc'd on any replies. Scott DAV svn SVNParentPath /var/svn # Authentication: Digest AuthName "Subversion repository" AuthType Digest AuthUserFile /etc/svn-auth.htdigest # Authorization: Authenticated users only Require valid-user How many repositories do you have? You shouldn't use SVNParentPath if you have only one repository; use SVNPath. I don't know if that is the direct cause of your problem, but you should fix it. I chose to use SVNParentPath on purpose. As soon as I have a secure, working server config, I'll be hosting multiple repos. Daniel and Thomas, thanks for your suggestions. My standard operating procedure is to get things working properly with a simple configuration, then add features one at a time. This helps isolate problems, especially when you are a beginner. I have containers in my httpd.conf files for various Web sites, domains, and SVN repositories, and you better believe I didn't try to configure everything at once! Try using SVNPath the first time and get it working securely before adding new capabilities. It's trivial to move a repository directory under Unix-like systems (and not very hard under Windows) to set up SVNParentPath later, so there is no reason to use SVNParentPath for a single repository. One last question, just in case: did you run "svnadmin create /var/svn" or "svnadmin create /var/svn/repo1"? In other words, is "/var/svn" a repository or a directory in which a repository was created? The directory in SVNParentPath shouldn't point to a repository, but to the parent directory of the repository (and its friends). I don't know if this would cause the security issues you are seeing, but it is a common enough mistake that I thought I would ask. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Issue 4039
On Mon, Aug 19, 2013 at 9:25 PM, Angelo Tavares wrote: > My case is creating subst working areas, which is not presented the features > of subversion. > Can you please give a bit more detail? What do you mean by "creating subst working areas"? Do you mean, for instance, that you have a working copy in C:\SomeDir\Project (which is the root of the working copy), and you execute "subst M: C:\SomeDir\Project"? If so, that works fine (just tried it with 1.7 and 1.8). But if you want "subst M: C:\SomeDir\Project\subdir", that won't work, and like Ivan said, will probably never be fixed (it really doesn't fit with the working copy design of 1.7+, where all SVN metadata is centralized in the root of the working copy). -- Johan
Re: server config
On 8/19/13 9:07 AM, Scott Frankel wrote: > I'm new to SVN server configuration and find myself setting up a CentOS 6.4 > server with svn version 1.6.1, following the red-bean book. I'd strongly urge you not to use 1.6.1, see the list of applicable security issues here: http://subversion.apache.org/security/ If you're using the CentOS packages they may have patched those issues without updating the svn version number. You should check that though. If you're setting a new server I wouldn't start with 1.6.x but would go straight to 1.7.x or 1.8.x, probably 1.8.x if you can. > I'm having difficulty with authorization &/or authentication: my repo > appears to be accessible by anyone in spite of requiring "valid-user" and > specifying digest authentication. I believe this because 1) I can download a > full working copy of the repo to a 3rd-party logged into a foreign computer, > and 2) I have dozens of entries in apache's logfiles, like these from this > morning, *prior* to any known/legitimate access to my repos today: > > svn_logfile: > [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity That does indeed look like access without a user. > access_log > 93.174.93.213 - - [19/Aug/2013:07:23:50 +] "GET > /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 319 "-" "ZmEu" > > error_log > [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not > exist: /var/www/html/MyAdmin These however do not appear to be alarming at all. Neither of them are under the /svn Location on your server where you have put the Require valid-user requirement. They appear to me to be just normal probes run by someone looking for security holes. This sort of thing is just going to be a normal part of running a server on the Internet. > > DAV svn > SVNParentPath /var/svn > > # Authentication: Digest > AuthName "Subversion repository" > AuthType Digest > AuthUserFile /etc/svn-auth.htdigest > > # Authorization: Authenticated users only > Require valid-user > I'm not seeing anything wrong with this, so I'm not sure why you're having a problem. You didn't mention it but I'm wondering what version of httpd you're running, I'm assuming 2.2.x since you're using 1.6.1 on CentOS 6.4.
Re: server config
I think he meant "subversion-1.6.11", which is the default version for CentOS 6.4. On Mon, Aug 19, 2013 at 6:19 PM, Ben Reser wrote: > On 8/19/13 9:07 AM, Scott Frankel wrote: > > I'm new to SVN server configuration and find myself setting up a CentOS > 6.4 server with svn version 1.6.1, following the red-bean book. > > I'd strongly urge you not to use 1.6.1, see the list of applicable > security issues here: > http://subversion.apache.org/security/ > > If you're using the CentOS packages they may have patched those issues > without updating the svn version number. You should check that though. > > If you're setting a new server I wouldn't start with 1.6.x but would go > straight to 1.7.x or 1.8.x, probably 1.8.x if you can. > > > I'm having difficulty with authorization &/or authentication: my repo > appears to be accessible by anyone in spite of requiring "valid-user" and > specifying digest authentication. I believe this because 1) I can download > a full working copy of the repo to a 3rd-party logged into a foreign > computer, and 2) I have dozens of entries in apache's logfiles, like these > from this morning, *prior* to any known/legitimate access to my repos today: > > > > svn_logfile: > > [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity > > That does indeed look like access without a user. > > > access_log > > 93.174.93.213 - - [19/Aug/2013:07:23:50 +] "GET > /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 319 "-" "ZmEu" > > > > error_log > > [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not > exist: /var/www/html/MyAdmin > > These however do not appear to be alarming at all. Neither of them are > under the /svn Location on your server where you have put the Require > valid-user requirement. They appear to me to be just normal probes run > by someone looking for security holes. This sort of thing is just going > to be a normal part of running a server on the Internet. > > > > > DAV svn > > SVNParentPath /var/svn > > > > # Authentication: Digest > > AuthName "Subversion repository" > > AuthType Digest > > AuthUserFile /etc/svn-auth.htdigest > > > > # Authorization: Authenticated users only > > Require valid-user > > > > I'm not seeing anything wrong with this, so I'm not sure why you're > having a problem. You didn't mention it but I'm wondering what version > of httpd you're running, I'm assuming 2.2.x since you're using 1.6.1 on > CentOS 6.4. > >
Re: server config
On 2013-08-20 01:41, Nico Kadel-Garcia wrote: > I think he meant "subversion-1.6.11", which is the default version for > CentOS 6.4. Check the SELinux settings in /etc/sysconfig/selinux. Set the line to 'SELINUX=permissive' (or disabled) After changing the SELINUX value a reboot is required Additional add a trailing '/' so you config looks so. RewriteEngine on # the trailing '/' in /svn/ is needed to browse repos with standart browser! RedirectMatch ^(/svn)$ $1/ DAV svn SVNParentPath /var/svn/ # Authentication: Digest AuthName "Subversion repository" AuthType Digest AuthUserFile /etc/svn-auth.htdigest # Authorization: Authenticated users only Require valid-user > > On Mon, Aug 19, 2013 at 6:19 PM, Ben Reser wrote: > >> On 8/19/13 9:07 AM, Scott Frankel wrote: >>> I'm new to SVN server configuration and find myself setting up a CentOS >> 6.4 server with svn version 1.6.1, following the red-bean book. >> >> I'd strongly urge you not to use 1.6.1, see the list of applicable >> security issues here: >> http://subversion.apache.org/security/ >> >> If you're using the CentOS packages they may have patched those issues >> without updating the svn version number. You should check that though. >> >> If you're setting a new server I wouldn't start with 1.6.x but would go >> straight to 1.7.x or 1.8.x, probably 1.8.x if you can. >> >>> I'm having difficulty with authorization &/or authentication: my repo >> appears to be accessible by anyone in spite of requiring "valid-user" and >> specifying digest authentication. I believe this because 1) I can download >> a full working copy of the repo to a 3rd-party logged into a foreign >> computer, and 2) I have dozens of entries in apache's logfiles, like these >> from this morning, *prior* to any known/legitimate access to my repos today: >>> >>> svn_logfile: >>> [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity >> >> That does indeed look like access without a user. >> >>> access_log >>> 93.174.93.213 - - [19/Aug/2013:07:23:50 +] "GET >> /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 319 "-" "ZmEu" >>> >>> error_log >>> [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not >> exist: /var/www/html/MyAdmin >> >> These however do not appear to be alarming at all. Neither of them are >> under the /svn Location on your server where you have put the Require >> valid-user requirement. They appear to me to be just normal probes run >> by someone looking for security holes. This sort of thing is just going >> to be a normal part of running a server on the Internet. >> >>> >>> DAV svn >>> SVNParentPath /var/svn >>> >>> # Authentication: Digest >>> AuthName "Subversion repository" >>> AuthType Digest >>> AuthUserFile /etc/svn-auth.htdigest >>> >>> # Authorization: Authenticated users only >>> Require valid-user >>> >> >> I'm not seeing anything wrong with this, so I'm not sure why you're >> having a problem. You didn't mention it but I'm wondering what version >> of httpd you're running, I'm assuming 2.2.x since you're using 1.6.1 on >> CentOS 6.4. >> >> >
