RE: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
Correct, default SSH port is not open on the corporate firewall. I am sure there are workarounds, however having contractual obligations not sure I should try hard to be unorthodox. SSH + SVN is my favourite and will stay with it as the primary access method. If I could top it with HTTP access using the existing Unix authentication and authorization framework, I would be more than happy. After all Unix works for tens of years, why to change it??? Other alternative would be to force Apache to spawn MOD_DAV_SVN processes as the authenticated user, wonder if it is possible, or has any inadvertent complications. B. > Date: Sat, 23 Nov 2013 01:07:16 +0200 > From: d...@daniel.shahaf.name > To: sbre...@hotmail.com > CC: users@subversion.apache.org > Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights > > sbre...@hotmail.com wrote on Thu, Nov 21, 2013 at 18:37:21 +: >> I am very happy with the SSH + 'svnserve' access to my repositories, >> however due to firewall issues I need access through HTTP as well. >> What I do not want is to set up a 2nd authentication / authorization >> database. > > What are the "firewall issues", exactly? Why can't you use svn+ssh? > Can you run sshd on port 80 (which would allow you to use svn+ssh > without httpd at all)? > > Daniel
Experiencing issue where CPU is pinned at 100% - more info
Config: OS: Windows 2012 Server 64bit 1TB SSD 8GiB RAM Software version4.0.2-3732.117 Subversion version 1.8.3-3732.117 Running since 11/21/2013 14:06:28 PST Repo health Total repositories: 2 - Go to the Repositories tab to create or discover repositories. Throughput on primary interface 0.0 B/s IN (over about 5 minutes); 0.0 B/s OUT (over about 5 minutes) Disk Usage as of 11/22/2013 11:10:31 PST Used space on root volume 565.43 GB Used space by repositories 138.65 GB Free space on repository volume 328.81 GB Authenticating with LDAP AD ~45 active user We migrated Two days ago. I dumped the repo to a new physical machine and imported it through the Web Interface. Every day, at some point, the repository becomes inaccessible. I RDC to the box and Apache is using 100% of the CPU. The entire machine is performing ridiculously slow. A restart of the Service restores CPU to normal and everyone carries on until the next occurrence. I parsed the error log for yesterday counting occurrences of all AH errors: occurrences: DEBUG Code 545112 AH01626: 206385 AH01691: 206377 AH01697: 139630 AH01384: 24 AH00361: 4 AH01316: 2 AH01320: 2 AH01318: 2 AH00408: 2 AH00403: 2 AH00348: 2 AH00334: 1 AH01284: 1 AH00456: 1 AH00455: 1 AH00453: 1 AH00431: 1 AH00422: 1 AH00418: 1 AH00411: 1 AH00407: 1 AH00402: 1 AH00391: 1 AH00359: 1 AH00357: 1 AH00354: 1 AH00352: 1 AH00096: 1 AH00094: I looked at the error log unto the point of the restart. I could not see anything obvious. I also look in the event viewer and see nothing. Dave Kelsey
Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
Gatting Apache to run suid processes and spawn mod_dav_svn processes has never worked for me, but it's been a long time since I tried it. It's also unnecessary in most setups: if the svn+ssh is owned by a single designated user, such as an "svn" user, with SSH heys stored for to apply the "ForceCommand" and set the particular svnserve user, then there is a common user's credentials that the Apache daemon merely needs write access to. That can be done with group permissions. It's not as safe as you might like, since the Apache related group and other hacked access to the web server could provide read and write repository access But one can provide both means of access, especially to share a publicly accessible repository. On Mon, Nov 25, 2013 at 5:24 AM, wrote: > Correct, default SSH port is not open on the corporate firewall. I am sure > there are workarounds, however having contractual obligations not sure I > should try hard to be unorthodox. > > SSH + SVN is my favourite and will stay with it as the primary access method. > If I could top it with HTTP access using the existing Unix authentication and > authorization framework, I would be more than happy. After all Unix works for > tens of years, why to change it??? > > Other alternative would be to force Apache to spawn MOD_DAV_SVN processes as > the authenticated user, wonder if it is possible, or has any inadvertent > complications. > > > B. > > >> Date: Sat, 23 Nov 2013 01:07:16 +0200 >> From: d...@daniel.shahaf.name >> To: sbre...@hotmail.com >> CC: users@subversion.apache.org >> Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights >> >> sbre...@hotmail.com wrote on Thu, Nov 21, 2013 at 18:37:21 +: >>> I am very happy with the SSH + 'svnserve' access to my repositories, >>> however due to firewall issues I need access through HTTP as well. >>> What I do not want is to set up a 2nd authentication / authorization >>> database. >> >> What are the "firewall issues", exactly? Why can't you use svn+ssh? >> Can you run sshd on port 80 (which would allow you to use svn+ssh >> without httpd at all)? >> >> Daniel
Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
sbre...@hotmail.com wrote on Mon, Nov 25, 2013 at 10:24:16 +: > Correct, default SSH port is not open on the corporate firewall. I am > sure there are workarounds, however having contractual obligations not > sure I should try hard to be unorthodox. I still suggest that you try to run sshd. If you can't convince them to open port 22, try to convince them to run sshd on port 1022. That's not unorthodox, it's common practice for evading vulnerability scanners and root-login-attemptors. Daniel > SSH + SVN is my favourite and will stay with it as the primary access method. > If I could top it with HTTP access using the existing Unix authentication and > authorization framework, I would be more than happy. After all Unix works for > tens of years, why to change it??? > > Other alternative would be to force Apache to spawn MOD_DAV_SVN processes as > the authenticated user, wonder if it is possible, or has any inadvertent > complications. > > > B. > > > > Date: Sat, 23 Nov 2013 01:07:16 +0200 > > From: d...@daniel.shahaf.name > > To: sbre...@hotmail.com > > CC: users@subversion.apache.org > > Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights > > > > sbre...@hotmail.com wrote on Thu, Nov 21, 2013 at 18:37:21 +: > >> I am very happy with the SSH + 'svnserve' access to my repositories, > >> however due to firewall issues I need access through HTTP as well. > >> What I do not want is to set up a 2nd authentication / authorization > >> database. > > > > What are the "firewall issues", exactly? Why can't you use svn+ssh? > > Can you run sshd on port 80 (which would allow you to use svn+ssh > > without httpd at all)? > > > > Daniel
Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
If you go to alternative SSH port, which is not that unusualy, write and show them the restricted sshd_config to restrict access to only that specified service for only that specified user. No password logins, no normal shells, use the authorized_keys ForceCommand access only for that alternative service. On Mon, Nov 25, 2013 at 5:43 AM, Daniel Shahaf wrote: > sbre...@hotmail.com wrote on Mon, Nov 25, 2013 at 10:24:16 +: >> Correct, default SSH port is not open on the corporate firewall. I am >> sure there are workarounds, however having contractual obligations not >> sure I should try hard to be unorthodox. > > I still suggest that you try to run sshd. If you can't convince them to > open port 22, try to convince them to run sshd on port 1022. That's not > unorthodox, it's common practice for evading vulnerability scanners and > root-login-attemptors. > > Daniel > >> SSH + SVN is my favourite and will stay with it as the primary access >> method. If I could top it with HTTP access using the existing Unix >> authentication and authorization framework, I would be more than happy. >> After all Unix works for tens of years, why to change it??? >> >> Other alternative would be to force Apache to spawn MOD_DAV_SVN processes as >> the authenticated user, wonder if it is possible, or has any inadvertent >> complications. >> >> >> B. >> >> >> > Date: Sat, 23 Nov 2013 01:07:16 +0200 >> > From: d...@daniel.shahaf.name >> > To: sbre...@hotmail.com >> > CC: users@subversion.apache.org >> > Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights >> > >> > sbre...@hotmail.com wrote on Thu, Nov 21, 2013 at 18:37:21 +: >> >> I am very happy with the SSH + 'svnserve' access to my repositories, >> >> however due to firewall issues I need access through HTTP as well. >> >> What I do not want is to set up a 2nd authentication / authorization >> >> database. >> > >> > What are the "firewall issues", exactly? Why can't you use svn+ssh? >> > Can you run sshd on port 80 (which would allow you to use svn+ssh >> > without httpd at all)? >> > >> > Daniel
Can't access SVN repos from command Line: Server SSL certificate untrusted
Hi, After upgrading the version of our svn server from 1.7 to 1.8, I'm not able to access from command line, for example, if I run* svn co* followed by the project svn URL here is what I get: [root@FPROD ~]# svn list https://svn-repo/svn/repos/project/trunk Error validating server certificate for 'https://svn-repo:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! - The certificate hostname does not match. Certificate information: - Hostname: T02PROD - Valid: from Nov 11 07:23:00 2013 GMT until Nov 11 07:23:00 2014 GMT - Issuer: SomeOrganizationalUnit, SomeOrganization, SomeCity, SomeState, -- (root@T02PROD) - Fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX (R)eject, accept (t)emporarily or accept (p)ermanently? p After accepting certificate, nothing shows and it remains planted until I tape* 'Ctrl + C"* to cancel it. Before upgrading svn server version, this problem never shows up and when I tought that is was related to the upgrade, I found that from one of the machines, where installed version 1.6 of svn client, accessing svn repo works fine. The only thing that comes in mind seeing this is that there is some sort of incompatibility between svn client 1.7 and svn server 1.8, but I'm not sure, it may be also because something is missing in my svn client installation. Hope you could help me solving this issue. Thanks in Advance Regards, Mehdi
Apache Subversion 1.7.14 released
I'm happy to announce the release of Apache Subversion 1.7.14. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release This release addresses two security issues: CVE-2013-4505: mod_dontdothat does not restrict requests from serf clients. CVE-2013-4558: mod_dav_svn assertion triggered by autoversioning commits. More information on these vulnerabilities, including the relevant advisories and potential attack vectors and workarounds, can be found on the Subversion security website: http://subversion.apache.org/security/ The SHA1 checksums are: 3875467f272cd3e78d12ac57dc42d6e690033494 subversion-1.7.14.zip b35254a844d0b221a3fd8e80974ac75119d77b94 subversion-1.7.14.tar.bz2 0bdea1c7c20598cd4b6869bf00f6df84fd17d769 subversion-1.7.14.tar.gz PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.14.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.14.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.14.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 Branko Čibej [4096R/A347943F] with fingerprint: BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F Johan Corveleyn [4096R/010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Julian Foad [4096R/4EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Fuhrmann [4096R/57921ACC] with fingerprint: 056F 8016 D9B8 7B1B DE41 7467 99EC 741B 5792 1ACC Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html You can find the list of changes between 1.7.14 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.14/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Apache Subversion 1.8.5 released
I'm happy to announce the release of Apache Subversion 1.8.5. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release This release addresses two security issues: CVE-2013-4505: mod_dontdothat does not restrict requests from serf clients. CVE-2013-4558: mod_dav_svn assertion triggered by autoversioning commits. More information on these vulnerabilities, including the relevant advisories and potential attack vectors and workarounds, can be found on the Subversion security website: http://subversion.apache.org/security/ The SHA1 checksums are: 2859de4cdce4494cecc7a71df4dfbf7a765d7759 subversion-1.8.5.tar.gz 66643c80041fedf585c8f4537331212e821aeef5 subversion-1.8.5.zip d21de7daf37d9dd1cb0f777e999a529b96f83082 subversion-1.8.5.tar.bz2 PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.5.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.5.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.5.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 Branko Čibej [4096R/A347943F] with fingerprint: BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Johan Corveleyn [4096R/010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Julian Foad [4096R/4EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Fuhrmann [4096R/57921ACC] with fingerprint: 056F 8016 D9B8 7B1B DE41 7467 99EC 741B 5792 1ACC Release notes for the 1.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.5 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.5/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
Nico Kadel-Garcia wrote on Mon, Nov 25, 2013 at 05:56:14 -0500: > use the authorized_keys ForceCommand access Minor correction: ForceCommand is a sshd_config(5) directive; the authorized_keys variant is spelled 'command="..."'.
Re: Can't access SVN repos from command Line: Server SSL certificate untrusted
Mehdi Hayani wrote on Mon, Nov 25, 2013 at 11:25:24 +: > - Fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX > (R)eject, accept (t)emporarily or accept (p)ermanently? p > > After accepting certificate, nothing shows and it remains planted until I > tape* 'Ctrl + C"* to cancel it. > Did you press after pressing ? Does it also happen if you pass --non-interactive --trust-server-cert to svn? (This is an attempt to rule out various timeout issues.) > Before upgrading svn server version, this problem never shows up When you upgraded the server, did you also upgrade mod_dav_svn only? Or did you also upgrade httpd and/or openssl at the same time?
Re: Can't access SVN repos from command Line: Server SSL certificate untrusted
On Mon, Nov 25, 2013 at 3:50 PM, Daniel Shahaf wrote: > Mehdi Hayani wrote on Mon, Nov 25, 2013 at 11:25:24 +: >> - Fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX >> (R)eject, accept (t)emporarily or accept (p)ermanently? p >> >> After accepting certificate, nothing shows and it remains planted until I >> tape* 'Ctrl + C"* to cancel it. >> > > Did you press after pressing ? > > Does it also happen if you pass --non-interactive --trust-server-cert to > svn? (This is an attempt to rule out various timeout issues.) > >> Before upgrading svn server version, this problem never shows up > > When you upgraded the server, did you also upgrade mod_dav_svn only? Or > did you also upgrade httpd and/or openssl at the same time? Also, why not give the CA (internal/private or external) you use for svn-repo to the clients?
Re: Can't access SVN repos from command Line: Server SSL certificate untrusted
[Forwarding back to the list] Mehdi Hayani wrote on Mon, Nov 25, 2013 at 21:05:42 +: > >When you upgraded the server, did you also upgrade mod_dav_svn only? Or > >did you also upgrade httpd and/or openssl at the same time? > > I don't know what was done exactly during the update, because there is > another team who take this in charge. > But I would appreciate if you can tell me what's the difference between > upgrading these packages You report something broke so everyone's first question is "What changed?". Part of "What changed?" is what exactly was upgraded. Daniel (please keep the list in CC on replies)
Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
Good point, thank you! On Mon, Nov 25, 2013 at 3:41 PM, Daniel Shahaf wrote: > Nico Kadel-Garcia wrote on Mon, Nov 25, 2013 at 05:56:14 -0500: >> use the authorized_keys ForceCommand access > > Minor correction: ForceCommand is a sshd_config(5) directive; the > authorized_keys variant is spelled 'command="..."'.
