date:20110728

SVN Error on Commit!!

2011-07-28 Thread Waseem Bokhari

Greetings!
   I am facing the following error on Commit in
Tortoise SVN:-
 
Pls Guide.
 
 
Commit failed (details follow):
Server sent unexpected return value (500 Internal Server Error) in response
to 
PUT request for
'/svn/nfs-cap-alamthal/!svn/wrk/ae7ebfe8-00e4-1f4b-ab19-6f510deb747e/Release
%20Workspace/Shipment/4.00.002%20Patch%2001/CAP%20WEB/Exe/Templates/Bassic_T
emplate/Local_Images/open-diary-normal.gif'
 
 
 


DISCLAIMER:  This e-mail and any file transmitted with it are confidential and 
intended solely 
for the use of the addressee.  If you are not the intended recipient, you are 
hereby advised that
any dissemination, distribution or copy of this email or its attachments is 
strictly prohibited.  If you
have received this email in error, please immediately notify us by return email 
and destroy this email 
message and its attachments.  This communication may contain forward-looking 
statements
relating to the development of NetSol Technologies' products and services and 
future operations.
The words "believe," "expect," "anticipate," "intend," variations of such 
words, and similar 
expressions, identify forward looking statements, but their absence does not 
mean that the 
statement is not forward-looking.  Views and opinions contained herein are 
those of the author of 
this email and do not necessarily represent those of NetSol Technologies.  
Statements contained 
herein are not guarantees of future performance and are subject to certain 
risks, uncertainties and 
assumptions that are difficult to predict. The company will not undertake to 
update any statements 
contained herein.

WARNING: The recipient should check this email and any attachment for the 
presence of viruses. 
Although the company has taken reasonable precautions to ensure no viruses are 
present in this 
email, the company does not accept responsibility for any loss or damage 
arising from the use of 
this email or attachment. Note: Please consider the environment before printing 
this e-mail.

FAIL: svnlook_tests.py 11: test 'svnlook * -t'

2011-07-28 Thread tsteven four

I have had failures of this test with 1.6.15 and 1.6.17 when running "make
check BASE_URL=http://server.domain"; on a client machine that is not the
server.  The server is also running the same version of subversion, but it
supports clients with multiple operating systems and I am testing a client
build.  I would welcome any suggestions in how to resolve this issue.


CMD: svnadmin create svn-test-work/repositories/svnlook_tests-11
--bdb-txn-nosync 
CMD: svnadmindump svn-test-work/local_tmp/repos | svnadminload
svn-test-work/repositories/svnlook_tests-11 --ignore-uuid 
CMD: svn co 
http://server.domain/svn-test-work/repositories/svnlook_tests-11svn-test-work/working_copies/svnlook_tests-11
--config-dir
/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom 
Asvn-test-work/working_copies/svnlook_tests-11/A
Asvn-test-work/working_copies/svnlook_tests-11/A/B
Asvn-test-work/working_copies/svnlook_tests-11/A/B/lambda
Asvn-test-work/working_copies/svnlook_tests-11/A/B/E
Asvn-test-work/working_copies/svnlook_tests-11/A/B/E/alpha
Asvn-test-work/working_copies/svnlook_tests-11/A/B/E/beta
Asvn-test-work/working_copies/svnlook_tests-11/A/B/F
Asvn-test-work/working_copies/svnlook_tests-11/A/mu
Asvn-test-work/working_copies/svnlook_tests-11/A/C
Asvn-test-work/working_copies/svnlook_tests-11/A/D
Asvn-test-work/working_copies/svnlook_tests-11/A/D/gamma
Asvn-test-work/working_copies/svnlook_tests-11/A/D/G
Asvn-test-work/working_copies/svnlook_tests-11/A/D/G/pi
Asvn-test-work/working_copies/svnlook_tests-11/A/D/G/rho
Asvn-test-work/working_copies/svnlook_tests-11/A/D/G/tau
Asvn-test-work/working_copies/svnlook_tests-11/A/D/H
Asvn-test-work/working_copies/svnlook_tests-11/A/D/H/chi
Asvn-test-work/working_copies/svnlook_tests-11/A/D/H/omega
Asvn-test-work/working_copies/svnlook_tests-11/A/D/H/psi
Asvn-test-work/working_copies/svnlook_tests-11/iota
Checked out revision 1.
CMD: svn ci -m "log msg" svn-test-work/working_copies/svnlook_tests-11
--config-dir
/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom 
Sendingsvn-test-work/working_copies/svnlook_tests-11/A/D/G/rho
Sendingsvn-test-work/working_copies/svnlook_tests-11/A/mu
Transmitting file data ..
Committed revision 2.
CMD: svn up svn-test-work/working_copies/svnlook_tests-11 --config-dir
/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom 
At revision 2.
wrong hook logfile content
EXPECTED STDOUT:
U   A/D/G/rho
U   A/mu
A/
A/D/G/
ACTUAL STDOUT:
EXCEPTION: SVNLineUnequal
Traceback (most recent call last):
  File
"/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svntest/main.py",
line 1226, in run
rc = self.pred.run(**kw)
  File
"/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svntest/testcase.py",
line 121, in run
return self.func(sandbox)
  File
"/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svnlook_tests.py",
line 599, in test_txn_flag
verify_logfile(logfilepath, expected_data)
  File
"/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svnlook_tests.py",
line 549, in verify_logfile
expected_data, actual_data)
  File
"/apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svntest/verify.py",
line 322, in compare_and_display_lines
raise raisable
SVNLineUnequal
FAIL:  svnlook_tests.py 11: test 'svnlook * -t'
END: svnlook_tests.py
ELAPSED: svnlook_tests.py 00:00:58

Re: FAIL: svnlook_tests.py 11: test 'svnlook * -t'

2011-07-28 Thread tsteven four

This appears to be a test bug that manifests itself when the tests are run
with a server and the svnlook binary being tested is not executable on the
server.  This is likely to occur if the server has a different machine
architecture or operating system than the subversion code being tested, but
certainly could occur in a variety of other circumstances.

There are two occurrences of this issue in svnlook_test.py.  In both cases a
hook script is created using the full path to the svnlook binary in the
subversion build under test. However, this binary may not be executable on
the server, and the hook script is executed on the server side.

One can get the test to pass by changing 'svntest.main.svnlook_binary' to
the full path to the binary on the server side in the code snippets from
svnlook_test.py below.  However, this path may not be known to the test
harness, and the purpose of the test is to test the current build, not a
different build that the server may be running.  So it may be more
appropriate to skip this test when the server is not using the build under
test.  Note that the server may or may not be using the build under test
when the BASE_URL refers to the http(s) protocol with a host other than
localhost, e.g. the host could be the fully qualified domain name of the
localhost or an alias for this host, or another machine that is executing
the build under test.

I believe this issue was introduced when the test was added in r918211 *Tue
Mar 2 21:54:13 2010 UTC* (16 months, 3 weeks ago) by *lgo *and it was
included in 1.6.10.

Please let me know if you agree with my analysis, and what can be done about
this issue.

Thanks.

  # 1. svnlook 'changed' -t and 'dirs-changed' -t
>   hook_instance = hook_template % (repr(svntest.main.svnlook_binary),
>repr([('changed', ''),
>  ('dirs-changed', '')]))
>   svntest.main.create_python_hook_script(pre_commit_hook,
>  hook_instance)
>
>   # 2. svnlook 'propget' -t, 'proplist' -t
>   # 2. Change a dir and revision property
>   hook_instance = hook_template % (repr(svntest.main.svnlook_binary),
>repr([('propget', 'bogus_prop /A'),
>  ('propget', '--revprop
> bogus_rev_prop'),
>  ('proplist', '/A'),
>  ('proplist', '--revprop')]))
>   svntest.main.create_python_hook_script(pre_commit_hook,
>  hook_instance)
>

On Wed, Jul 27, 2011 at 3:45 PM, tsteven four  wrote:

> I have had failures of this test with 1.6.15 and 1.6.17 when running "make
> check BASE_URL=http://server.domain"; on a client machine that is not the
> server.  The server is also running the same version of subversion, but it
> supports clients with multiple operating systems and I am testing a client
> build.  I would welcome any suggestions in how to resolve this issue.
>
>
> CMD: svnadmin create svn-test-work/repositories/svnlook_tests-11
> --bdb-txn-nosync 
> CMD: svnadmindump svn-test-work/local_tmp/repos | svnadminload
> svn-test-work/repositories/svnlook_tests-11 --ignore-uuid 
> CMD: svn co
> http://server.domain/svn-test-work/repositories/svnlook_tests-11svn-test-work/working_copies/svnlook_tests-11
>  --config-dir
> /apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svn-test-work/local_tmp/config
> --password rayjandom --no-auth-cache --username jrandom 
> Asvn-test-work/working_copies/svnlook_tests-11/A
> Asvn-test-work/working_copies/svnlook_tests-11/A/B
> Asvn-test-work/working_copies/svnlook_tests-11/A/B/lambda
> Asvn-test-work/working_copies/svnlook_tests-11/A/B/E
> Asvn-test-work/working_copies/svnlook_tests-11/A/B/E/alpha
> Asvn-test-work/working_copies/svnlook_tests-11/A/B/E/beta
> Asvn-test-work/working_copies/svnlook_tests-11/A/B/F
> Asvn-test-work/working_copies/svnlook_tests-11/A/mu
> Asvn-test-work/working_copies/svnlook_tests-11/A/C
> Asvn-test-work/working_copies/svnlook_tests-11/A/D
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/gamma
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/G
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/G/pi
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/G/rho
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/G/tau
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/H
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/H/chi
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/H/omega
> Asvn-test-work/working_copies/svnlook_tests-11/A/D/H/psi
> Asvn-test-work/working_copies/svnlook_tests-11/iota
> Checked out revision 1.
> CMD: svn ci -m "log msg" svn-test-work/working_copies/svnlook_tests-11
> --config-dir
> /apps/install/subversion-1.6.17-Linux_x86_64/subversion/tests/cmdline/svn-test-work/local_tmp/config
> --pas

Subversion version 7.0 Beta2 release configure attempt error

2011-07-28 Thread Rob Patten


Noting the Subversion 7.0 Beta2 is released we are attempting to get
ahead start on user request to have Subversion install on our IBM
servers. Our user community requested any near current version at least
but notified they will require version 7.0 for their project needs. We
have had difficulty in the past getting all the dependencies to
configure correctly. Currently attempting this under AIX 5.3 but intend
to use it under AIX 6.1 and 7.1 too. We understand that this version 7.0
is not fully released yet but if we can get it to configure and install
would save us considerable effort in the near future. Of course we would
like to get any version of Subversion to install on AIX too. The
dependencies always seem to be the issue.

I confirm that I did apply the dependency get-deps.sh successfully. Have
tried numerous configure attempts to see if I can get it work within the
package source directory. We hope to easily move it from server to
server if this works. Getting what appears to be only one dependency
error related to APR-util indicated. Any help or recommendations would
be appreciated:

Package file listing
r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-beta2 ->ls -l
total 3728
-rw-rw-r--1 3300 3300  0 Jul 21 23:11 .swig_checked
-rw-rw-r--1 3300 3300 94 Feb 22 2010  BUGS
-rw-rw-r--1 3300 3300 186579 Jul 21 16:51 CHANGES
-rw-rw-r--1 3300 3300  12956 Jun 27 11:16 COMMITTERS
-rw-rw-r--1 3300 3300  64417 Jul 08 05:40 INSTALL
-rw-rw-r--1 3300 3300  14214 Feb 03 2010  LICENSE
-rw-rw-r--1 3300 3300  34568 Jul 16 07:50 Makefile.in
-rw-rw-r--1 3300 3300593 Mar 27 23:54 NOTICE
-rw-rw-r--1 3300 3300   2301 Jun 30 13:54 README
-rw-rw-r--1 3300 3300   2028 Dec 07 2009  aclocal.m4
drwxr-xr-x   25 1000 1000   1536 Jul 26 15:56 apr
drwxr-xr-x   19 1000 1000   1024 May 19 10:58 apr-util
-rwxrwxr-x1 3300 3300   6256 Jul 04 06:24 autogen.sh
drwxrwxr-x6 3300 3300   1024 Jul 21 23:12 build
-rw-rw-r--1 3300 3300 568333 Jul 21 23:12 build-outputs.mk
-rw-rw-r--1 3300 3300  34702 Jul 08 19:23 build.conf
-rw-rw-r--1 root system16193 Jul 26 15:56 config.log
-rwxrwxr-x1 root system  297 Jul 26 15:50 config.nice
-rwxrwxr-x1 3300 3300 790792 Jul 21 23:12 configure
-rw-rw-r--1 3300 3300  46645 Jul 16 07:49 configure.ac
drwxrwxr-x4 3300 3300512 Jul 21 23:11 doc
-rw-rw-r--1 3300 3300 23 Jul 21 23:12 gen-make.opts
-rwxrwxr-x1 3300 3300  10604 Mar 25 12:30 gen-make.py
-rwxrwxr-x1 3300 3300   3444 Jun 25 20:23 get-deps.sh
drwxrwxr-x7 500  cfgsoft1024 May 03 08:25 neon
drwxr-xr-x6 1000 1000512 Mar 12 12:43 serf
drwxr-xr-x2 root system  512 May 19 09:35
sqlite-amalgamation
drwxrwxr-x   33 3300 3300   1024 Jul 21 23:12 subversion
drwxrwxr-x   14 3300 3300512 Jul 21 23:10 tools
-rw-rw-r--1 3300 3300  27426 Jul 12 14:30 win-tests.py
drwxr-xr-x   12 csi_acct perf   1536 Apr 20 2010  zlib


Package dependency install:

r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-beta2 ->./get-deps.sh
--2011-07-26 10:56:44--
http://archive.apache.org/dist/apr/apr-1.4.5.tar.bz2
Resolving archive.apache.org... 140.211.11.131
Connecting to archive.apache.org|140.211.11.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 754763 (737K) [application/x-bzip2]
Saving to: apr-1.4.5.tar.bz2

100%[=>]
754,763  936K/s   in 0.8s

2011-07-26 10:56:46 (936 KB/s) - apr-1.4.5.tar.bz2 saved [754763/754763]

--2011-07-26 10:56:46--
http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.bz2
Resolving archive.apache.org... 140.211.11.131
Connecting to archive.apache.org|140.211.11.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 607646 (593K) [application/x-bzip2]
Saving to: apr-util-1.3.12.tar.bz2

100%[=>]
607,646  807K/s   in 0.7s

2011-07-26 10:56:47 (807 KB/s) - apr-util-1.3.12.tar.bz2 saved
[607646/607646]

--2011-07-26 10:56:57--  http://webdav.org/neon/neon-0.29.6.tar.gz
Resolving webdav.org... 140.211.166.111
Connecting to webdav.org|140.211.166.111|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 882267 (862K) [application/x-tar]
Saving to: neon-0.29.6.tar.gz

100%[=>]
882,267  787K/s   in 1.1s

2011-07-26 10:57:00 (787 KB/s) - neon-0.29.6.tar.gz saved [882267/882267]

--2011-07-26 1

Re: Subversion version 7.0 Beta2 release configure attempt error

2011-07-28 Thread Giulio Troccoli




On 27/07/11 15:28, Rob Patten wrote:

Noting the Subversion 7.0 Beta2 is released we are attempting to get
ahead start on user request to have Subversion install on our IBM
servers. Our user community requested any near current version at least
but notified they will require version 7.0 for their project needs. We
have had difficulty in the past getting all the dependencies to
configure correctly. Currently attempting this under AIX 5.3 but intend
to use it under AIX 6.1 and 7.1 too. We understand that this version 7.0
is not fully released yet but if we can get it to configure and install
would save us considerable effort in the near future. Of course we would
like to get any version of Subversion to install on AIX too. The
dependencies always seem to be the issue.

I confirm that I did apply the dependency get-deps.sh successfully. Have
tried numerous configure attempts to see if I can get it work within the
package source directory. We hope to easily move it from server to
server if this works. Getting what appears to be only one dependency
error related to APR-util indicated. Any help or recommendations would
be appreciated:

Package file listing
r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-beta2 ->ls -l
total 3728
-rw-rw-r--1 3300 3300  0 Jul 21 23:11 .swig_checked
-rw-rw-r--1 3300 3300 94 Feb 22 2010  BUGS
-rw-rw-r--1 3300 3300 186579 Jul 21 16:51 CHANGES
-rw-rw-r--1 3300 3300  12956 Jun 27 11:16 COMMITTERS
-rw-rw-r--1 3300 3300  64417 Jul 08 05:40 INSTALL
-rw-rw-r--1 3300 3300  14214 Feb 03 2010  LICENSE
-rw-rw-r--1 3300 3300  34568 Jul 16 07:50 Makefile.in
-rw-rw-r--1 3300 3300593 Mar 27 23:54 NOTICE
-rw-rw-r--1 3300 3300   2301 Jun 30 13:54 README
-rw-rw-r--1 3300 3300   2028 Dec 07 2009  aclocal.m4
drwxr-xr-x   25 1000 1000   1536 Jul 26 15:56 apr
drwxr-xr-x   19 1000 1000   1024 May 19 10:58 apr-util
-rwxrwxr-x1 3300 3300   6256 Jul 04 06:24 autogen.sh
drwxrwxr-x6 3300 3300   1024 Jul 21 23:12 build
-rw-rw-r--1 3300 3300 568333 Jul 21 23:12 build-outputs.mk
-rw-rw-r--1 3300 3300  34702 Jul 08 19:23 build.conf
-rw-rw-r--1 root system16193 Jul 26 15:56 config.log
-rwxrwxr-x1 root system  297 Jul 26 15:50 config.nice
-rwxrwxr-x1 3300 3300 790792 Jul 21 23:12 configure
-rw-rw-r--1 3300 3300  46645 Jul 16 07:49 configure.ac
drwxrwxr-x4 3300 3300512 Jul 21 23:11 doc
-rw-rw-r--1 3300 3300 23 Jul 21 23:12 gen-make.opts
-rwxrwxr-x1 3300 3300  10604 Mar 25 12:30 gen-make.py
-rwxrwxr-x1 3300 3300   3444 Jun 25 20:23 get-deps.sh
drwxrwxr-x7 500  cfgsoft1024 May 03 08:25 neon
drwxr-xr-x6 1000 1000512 Mar 12 12:43 serf
drwxr-xr-x2 root system  512 May 19 09:35
sqlite-amalgamation
drwxrwxr-x   33 3300 3300   1024 Jul 21 23:12 subversion
drwxrwxr-x   14 3300 3300512 Jul 21 23:10 tools
-rw-rw-r--1 3300 3300  27426 Jul 12 14:30 win-tests.py
drwxr-xr-x   12 csi_acct perf   1536 Apr 20 2010  zlib


Package dependency install:

r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-beta2 ->./get-deps.sh
--2011-07-26 10:56:44--
http://archive.apache.org/dist/apr/apr-1.4.5.tar.bz2
Resolving archive.apache.org... 140.211.11.131
Connecting to archive.apache.org|140.211.11.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 754763 (737K) [application/x-bzip2]
Saving to: apr-1.4.5.tar.bz2

100%[=>]
754,763  936K/s   in 0.8s

2011-07-26 10:56:46 (936 KB/s) - apr-1.4.5.tar.bz2 saved [754763/754763]

--2011-07-26 10:56:46--
http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.bz2
Resolving archive.apache.org... 140.211.11.131
Connecting to archive.apache.org|140.211.11.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 607646 (593K) [application/x-bzip2]
Saving to: apr-util-1.3.12.tar.bz2

100%[=>]
607,646  807K/s   in 0.7s

2011-07-26 10:56:47 (807 KB/s) - apr-util-1.3.12.tar.bz2 saved
[607646/607646]

--2011-07-26 10:56:57--  http://webdav.org/neon/neon-0.29.6.tar.gz
Resolving webdav.org... 140.211.166.111
Connecting to webdav.org|140.211.166.111|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 882267 (862K) [application/x-tar]
Saving to: neon-0.29.6.tar.gz

100%[=>]
882,267  787K/s   in 1.1s

2011-07-26 10:57:00 (787 KB/s) - neon-0.29.6.tar.

Re: disable security hole in svn+ssh?

2011-07-28 Thread Andy Canfield




On 07/27/2011 06:47 PM, Nico Kadel-Garcia wrote:

On Wed, Jul 27, 2011 at 12:06 AM, Andy Canfield
  wrote:

I was trying to get http, svn, and svn+ssh to work.

Dude. Pick one. Getting all three to play nicely together is destablilizing.
For me, getting any of the four to work is difficult. Here is the status 
of the various protocols, in order by apparent desirability. The 
problems are in parentheses.


Server:Test   Production
Network:  on LAN on Internet
  ---
1. HTTPS: (config) (config)
2. HTTP: OK   (software mismatch)
3. SVN:  OK   (port not forwarded)
4. SVN+SSH:  (security)   (security)

Now you see why I'm trying to get any of them working. Every alternative 
has a problem. I can't get HTTPS to work at all. HTTP on the production 
server fails due to a software mismatch which we may not be able to fix; 
the distro from Apple seems to be bad. SVN requires our ISP to change 
our Router settings. SVN+SSH authentication worksfor me without 
authorization checking.



HERE IT IS USING HTTP:
Â Â Â  svn infohttp://athol/svn/subdoc
Authentication realm:  Athol Subversion Repository
Password for 'andy':
Path: subdoc
URL:http://athol/svn/subdoc
Repository Root:http://athol/svn/subdoc
Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
Revision: 4
Node Kind: directory
Last Changed Author: andy
Last Changed Rev: 4
Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)

Hold it right there. You're providing password based repository access
via HTTP, not HTTPS? Please rethink this unless you *want* the
passwords for this repository to be quite insecure and sniffable,
especially if you're using normal user login passwords.
If HTTP sends passwords in as plain text then yes, HTTPS is better. But 
I can't get HTTPS to work at all. I get the impression from googling 
that HTTPS requires a certificate, and I don't have a certificate. If I 
could generate my own certificate, we could tell our developers "Accept 
this certificate the first time you see it, and after that it will work 
every time."



Also note. For HTTP access from Linux and UNIX systems, the default
behavior is to store the password, in cleartext, in
$HOME/.subversioon/. *That* is a longstanding security issue that I've
been ranting about for *years*. Subversion 1.6.x, very reasonably, now
asks for permission before doing that, But if you're using the same
password authenticatoin for svn+ssh://,http://,https://, and svn://
based access, you're now writing your password in plain text. locally.
svn+ssh:// doesn't recored that plain text password,http://  and
htps:// do.

HERE IT IS USING SVN:
Â Â Â  svn info svn://athol/subdoc
Authentication realm:  Subversion svnserve
Password for 'andy':
Path: subdoc
URL: svn://athol/subdoc
Repository Root: svn://athol/subdoc
Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
Revision: 4
Node Kind: directory
Last Changed Author: andy
Last Changed Rev: 4
Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)

Again. Unencrypted passwords, unless you're using something like SASL.
Do not use this for normal user passwords.
Unencrypted passwords stored on the server. We can make the file 
accessable only by the Apache user. Not ideal, but not bad. If the 
hacker roots the server we've got no security anyway.

HERE IS THE PROBLEM USING SVN+SSH:
Â Â Â  svn info svn+ssh://athol/data/svn/subdoc
The authenticity of host 'athol (192.168.1.113)' can't be established.
ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7.
Are you sure you want to continue connecting (yes/no)? yes
kids@athol's password:
Path: subdoc
URL: svn+ssh://athol/data/svn/subdoc
Repository Root: svn+ssh://athol/data/svn/subdoc
Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
Revision: 4
Node Kind: directory
Last Changed Author: andy
Last Changed Rev: 4
Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)

What's 'worse' about it? Well, 'kids' is a valid user name on the server;

Which it need not be. The gudebook does not make this clear enough:
For users who have normal shell access *anyway*, many sites do use
this approach and simply set the repository to be manged with group
access to designated users. But in the "we don't want people to need
shell access to use svn+ssh", you need to set up something like an SSH
key on a shared account with forced commands, typically with this kind
of URL.

 svn+ssh://svn@sitename/svn/reponame/
Near as I can tell svn+ssh uses ssh for authentication but it does not 
seem to do any authorization at all. At that point anybody with an SSH 
login can do anything; there is no authorization phase for svn+ssh. I am 
trying to fix that, perhaps using an authz file in every repository, but 
haven't got it working yet.



That "svn" user can be set to have no valid shell, with its shell set
to something like "/sbin/nologin". This is actuall

Re: disable security hole in svn+ssh?

2011-07-28 Thread Matthew Beals

> That "svn" user can be set to have no valid shell, with its shell set
> to something like "/sbin/nologin". This is actually quite common for
> system services to have no valid shell. This is how the "apache" or
> "www-data" user is usually set up.
But that would prevent login using ssh, which I don't want. I can tell 
the sysadmin "we need an SSH login for Charlie so he can use 
Subversion", but I cannot say "You have to cut the SSH login for Marilyn 
so she can't use Subversion".

*Truncated for clarity*
One option would be to generate a different (password enabled... of course) key 
for each unique user (all logging in with the same SVN user name).  Then 
revoking SVN access is as simple as removing that user's key from the 
authorized_keys list.  





Matthew Beals
Michigan Technological University
Department of Atmospheric Sciences
1400 Townsend Drive
B019a Fisher Hall
Houghton, MI 49931
mjbe...@mtu.edu

Re: disable security hole in svn+ssh?

2011-07-28 Thread Geoff Hoffman

On Thu, Jul 28, 2011 at 7:29 AM, Andy Canfield wrote:

> Hold it right there. You're providing password based repository access
>> via HTTP, not HTTPS? Please rethink this unless you *want* the
>> passwords for this repository to be quite insecure and sniffable,
>> especially if you're using normal user login passwords.
>>
> If HTTP sends passwords in as plain text then yes, HTTPS is better. But I
> can't get HTTPS to work at all. I get the impression from googling that
> HTTPS requires a certificate, and I don't have a certificate. If I could
> generate my own certificate, we could tell our developers "Accept this
> certificate the first time you see it, and after that it will work every
> time."
>

> So there are actually four protocols that a workstation can use to access a
> Subversion repository: http, https, svn:, and svn+ssh. Assuming that I pick
> one, how do I turn the others off? If James Bond can access via https, how
> can we prevent him from using http and blowing the security? iIf James Bond
> has an ssh login account on the server, but should not be using Subversion
> at all,  how do we prevent him from using svn+ssh:? How do we prevent him
> from logging in and using file:? How do we prevent him from logging in and
> running svnadmin?
>

Wow Andy, you have really put SVN security through the ringer and bring up
some really good points. We're hosting svn behind our firewall on http and
so our users have to have a VPN to connect. This of course requires a
certain type of security appliance (several hundred bucks at a minimum.)

Some of our users have ssh login on the same box running svn but I never
thought to secure svnadmin or prevent svn+ssh so I never really thought
about it at the level you are doing. You can chroot users [2] into their
home dir if you go with svn+ssh... Matt's suggestion to generate ssh keys
for everyone is a good idea also (as well as making it simpler to connect in
a development workflow)

I would think https would be your best bet; you can make a self signed
certificate[1] but even an actual SSL isn't that hard to install and only
$20/yr from GoDaddy, for example. You can then detect http protocol with a
rewrite rule and redirect to https using mod_rewrite in either the vhost
container or .htaccess file.

Have you thought of getting some paid help from, e.g., CollabNet [3]? Maybe
well worth it in your case. (Case STUDY more like it!)

[1]
https://help.ubuntu.com/8.04/serverguide/C/certificates-and-security.html
[2] https://help.ubuntu.com/community/BasicChroot
[3] http://www.open.collab.net/consulting/

Re: disable security hole in svn+ssh?

2011-07-28 Thread Les Mikesell


On 7/28/2011 9:29 AM, Andy Canfield wrote:



I was trying to get http, svn, and svn+ssh to work.

Dude. Pick one. Getting all three to play nicely together is
destablilizing.

For me, getting any of the four to work is difficult. Here is the status
of the various protocols, in order by apparent desirability. The
problems are in parentheses.

Server: Test Production
Network: on LAN on Internet
 ---
1. HTTPS: (config) (config)
2. HTTP: OK (software mismatch)
3. SVN: OK (port not forwarded)
4. SVN+SSH: (security) (security)

Now you see why I'm trying to get any of them working. Every alternative
has a problem. I can't get HTTPS to work at all. HTTP on the production
server fails due to a software mismatch which we may not be able to fix;
the distro from Apple seems to be bad.


Hardware is cheap.  More than one OS distribution with a working, 
packaged subversion is free.  Why are you fighting with something that 
doesn't work?  I'd be very surprised if you really can't run mod_dav_svn 
on OSX, though.  Worst case should be that you grab the apache source 
and recompile the whole thing together to make sure the modules match.



If HTTP sends passwords in as plain text then yes, HTTPS is better. But
I can't get HTTPS to work at all. I get the impression from googling
that HTTPS requires a certificate, and I don't have a certificate. If I
could generate my own certificate, we could tell our developers "Accept
this certificate the first time you see it, and after that it will work
every time."


Yes, that is pretty common for private use.  And the stock apache setup 
for a linux distribution may already include this.



svn+ssh://svn@sitename/svn/reponame/

Near as I can tell svn+ssh uses ssh for authentication but it does not
seem to do any authorization at all. At that point anybody with an SSH
login can do anything; there is no authorization phase for svn+ssh. I am
trying to fix that, perhaps using an authz file in every repository, but
haven't got it working yet.


It starts its own svnserve as that user.  If you don't want them to have 
access at all, use filesystem settings to block them (i.e. don't put 
them in the group that has access).  Beyond that, use an authz file.



That "svn" user can be set to have no valid shell, with its shell set
to something like "/sbin/nologin". This is actually quite common for
system services to have no valid shell. This is how the "apache" or
"www-data" user is usually set up.

But that would prevent login using ssh, which I don't want. I can tell
the sysadmin "we need an SSH login for Charlie so he can use
Subversion", but I cannot say "You have to cut the SSH login for Marilyn
so she can't use Subversion".


That suggestion was for using a shared login for svn.  If you don't want 
shared logins you could create new individual logins just for use with 
svn.  Given your borked OS, that might be the quick fix for you. Add 
user_svn logins for each user that should have svn access, make keys for 
them but don't give out the passwords.  Then restrict the ssh command 
that can be issued with those keys.  A little extra setup work but 
nothing complicated.



I think it does do what I think it does.
<== The current directory is /a/b/c
mkdir t <== create /a/b/c/t
cd t <== The current directory is /a/b/c/t
svn checkout svn+ssh://example.com/data/svn/subdoc <== /a/b/c/t is a
working copy
svn delete * <== delete everything in this working copy on next commit
svn commit <== New revision, deletes everything


Note that this does not delete anything that already exists in the 
repository - which is a large part of why you use revision control.  It 
will make a new head revision where the things the client deleted do not 
appear.  You can still check out or update to the earlier revision where 
it does exist.  And you can view the logs to see who did it and when. 
The thing you really need to protect against is filesystem write access 
to delete or scramble the server's copy of the repository files - and 
you should have a fairly up to date backup on a more restricted system 
in any case.



But users that Subversion has never heard of should not have that power.
My testing of svn+ssh indicates that once ssh authenticates a user,
svnserve does not seem to check authorization at all. That's my problem.


They are running under their own uid.  If that uid can't write to the 
repository files, they can't modify anything.  But, didn't you say 
something about making svnserve setuid a while back?  That would break 
things.



Frankly, I think people are a lot safer with the svn+ssh:// because of
the password handling.

I can get authentication but cannot yet get suthorization.


Having _any_ write access comes from filesystem permissions.  Making it 
more granular needs an authz file.



So there are actually four protocols that a workstation can use to
access a Subversion repository: http, https, svn:, and svn+ssh. Assuming
that I pick one, how do I tu

Re: SVN Error on Commit!!

2011-07-28 Thread Ryan Schmidt

On Jul 28, 2011, at 07:34, Waseem Bokhari wrote:

> Greetings!
>I am facing the following error on Commit in 
> Tortoise SVN:-
>  
> Pls Guide.
>  
>  
> Commit failed (details follow):
> Server sent unexpected return value (500 Internal Server Error) in response to
> PUT request for 
> '/svn/nfs-cap-alamthal/!svn/wrk/ae7ebfe8-00e4-1f4b-ab19-6f510deb747e/Release%20Workspace/Shipment/4.00.002%20Patch%2001/CAP%20WEB/Exe/Templates/Bassic_Template/Local_Images/open-diary-normal.gif'

Really hard to know what to suggest with so little information.

What version of TortoiseSVN on the client? What version of SVN on the server? 
What OS on the server?

What communication method? Can you show us the server configuration files?

Does it happen with every commit and every file? Or only this file? Or only 
this once? Or only sometimes?

Can you reproduce the issue at will? What about in a clean repository?

Does it happen only for this user, or for all users?

What if you use a different client program? What about a different client 
computer?

1.7 apr-util --with-expat=builtin configure option

2011-07-28 Thread tsteven four

With 1.6 I sometimes had to pass the option '--with-expat=builtin' to the
subversion configuration script so the apr-util would be built with the
included expat instead of the system expat.  This avoided RPATH problems
that would result in libaprutil picking up libapr from the system instead of
from the subversion build directory (and other similar downstream
problems).  With 1.7 the subversion configure script now rejects
'--with-expat=builtin'.  How can I use expat included in apr-util, which has
not been built or installed at the time subversion is configured?  The
subversion configuration help now states
"--with-expat=INCLUDES:LIB_SEARCH_DIRS:LIBS  Specify location of Expat", but
it is not clear to me how to set this so that apr-util is configured with
--with-expat=builtin, or the equivalent result is achieved.

Thanks

Re: disable security hole in svn+ssh?

2011-07-28 Thread Nico Kadel-Garcia

On Thu, Jul 28, 2011 at 10:44 AM, Matthew Beals  wrote:
>> That "svn" user can be set to have no valid shell, with its shell set
>> to something like "/sbin/nologin". This is actually quite common for
>> system services to have no valid shell. This is how the "apache" or
>> "www-data" user is usually set up.
> But that would prevent login using ssh, which I don't want. I can tell
> the sysadmin "we need an SSH login for Charlie so he can use
> Subversion", but I cannot say "You have to cut the SSH login for Marilyn
> so she can't use Subversion".

You've got a basic misapprehension here. They do not use their own
shell access for Subversion. It is *divorced* from normal shell
access. They still have their shell for non-Subverson access, but for
Subversion, they have to come in as the "svn" user with the
"svn+ssh://svn@hostname/reponame/" access, with SSH keys. Notice that
"svn@" bit? That targets the access through that shared user.

This is similar to what HTTP and svnservice access do: the service in
those cases runs as a local daemon with a non-shell enabled user.

> *Truncated for clarity*
> One option would be to generate a different (password enabled... of course) 
> key for each unique user (all logging in with the same SVN user name).  Then 
> revoking SVN access is as simple as removing that user's key from the 
> authorized_keys list.

You are confusing authorized_keys usage with password access. You have
utterly no control, as an admin, Even if you generate SSH private keys
and nissue them to users, with passphrases, you have no way to prevent
them from stripping out the passphrase protection. This is a long,
long standing security risk of common SSH user behavior: people get
tired of having to unlock keys and get tempted to use passphrase free
keys, especially for Subversion, and won't bother to use an ssh-agent
or other key management tool to keep a locally unlocked tool for
passphrase Subversion usage. And you, as a network admin, have little
leverage to make them use keys properly.

It drives me nuts, and I've said that it's a fundamental flaw in the
ssh-keygen software that it allows this behavior by default.

Re: disable security hole in svn+ssh?

2011-07-28 Thread Andy Canfield


Thank you very much.

On 07/28/2011 09:48 PM, Geoff Hoffman wrote:


On Thu, Jul 28, 2011 at 7:29 AM, Andy Canfield 
mailto:andy.canfi...@pimco.mobi>> wrote:



Hold it right there. You're providing password based
repository access
via HTTP, not HTTPS? Please rethink this unless you *want* the
passwords for this repository to be quite insecure and sniffable,
especially if you're using normal user login passwords.

If HTTP sends passwords in as plain text then yes, HTTPS is
better. But I can't get HTTPS to work at all. I get the impression
from googling that HTTPS requires a certificate, and I don't have
a certificate. If I could generate my own certificate, we could
tell our developers "Accept this certificate the first time you
see it, and after that it will work every time."




So there are actually four protocols that a workstation can use to
access a Subversion repository: http, https, svn:, and svn+ssh.
Assuming that I pick one, how do I turn the others off? If James
Bond can access via https, how can we prevent him from using http
and blowing the security? iIf James Bond has an ssh login account
on the server, but should not be using Subversion at all,  how do
we prevent him from using svn+ssh:? How do we prevent him from
logging in and using file:? How do we prevent him from logging in
and running svnadmin?




Wow Andy, you have really put SVN security through the ringer and 
bring up some really good points.


Actually the people in this group are a lot more concerned with security 
than I am.


Here I learned the difference between authentication and authorization. 
I can trust the standard system alternatives for authentication - ssh, 
http, https, SSL, whatever. It all winds up being "This guy is Charlie". 
Then the question is, what is Charlie allowed to do? Seems like every 
protocol uses a different method to do authorization, and that's my 
ignorance. I'm trying to work out an authorization mechanism that 
applies regardless of the protocol.


In recent years Linux has gone the route that a valid logged-in user can 
read nearly anything. Can't change it, but can read it. Chalie can read 
/etc/apache2/mods-enabled/mod_dav_svn.conf. But he can't change it. I 
can live with that. Because we could have valuable trade secrets in a 
Subversion repository, I would prefer to limit read access, but if that 
isn't available so be it. But I am a little horrified that Charlie can 
create repositories without any authorization at all.


I keep comparing Subversion to MySQL. They both store data for you. A 
repository is like a database. But the average user is not allowed to 
create databases! Everything you do with MySQL - create, drop, update, 
select, etc. - goes through the same piece of code; the server. So the 
MySQL authorization scheme is exactly the same regardless of how you get 
to the server; it's built into the server, not the protocol.


Apparently, regardless of the protocol, the Subversion library code 
always checks $SVNParentPath/$Repository/conf/* and obeys svnserve.conf 
and authz. So I need to learn to use that effectively.


We're hosting svn behind our firewall on http and so our users have to 
have a VPN to connect. This of course requires a certain type of 
security appliance (several hundred bucks at a minimum.)
In case it hasn't been obvious, I'm in southeast Asia, definitely third 
world turf. And this is a startup, with stingy investors.
Some of our users have ssh login on the same box running svn but I 
never thought to secure svnadmin or prevent svn+ssh so I never really 
thought about it at the level you are doing. You can chroot users [2] 
into their home dir if you go with svn+ssh... Matt's suggestion to 
generate ssh keys for everyone is a good idea also (as well as making 
it simpler to connect in a development workflow)


I would think https would be your best bet; you can make a self signed 
certificate[1] but even an actual SSL isn't that hard to install and 
only $20/yr from GoDaddy, for example.

Yes, HTTPS sounds like the best method.

I hate incorrect error messages. I once changed banks because their ATM 
error messages were wrong. When I try to HTTPS into a serer that's not 
configured for it FIrefox gives me an error message that says the server 
response string was too long. That sounds like B.S. to me. Thanks to 
you, I can make a certificate.


You can then detect http protocol with a rewrite rule and redirect to 
https using mod_rewrite in either the vhost container or .htaccess file.

Where would the .htaccess file be for svn+ssh? There's no directory!


Have you thought of getting some paid help from, e.g., CollabNet [3]? 
Maybe well worth it in your case. (Case STUDY more like it!)



[1] 
https://help.ubuntu.com/8.04/serverguide/C/certificates-and-security.html

[2] https://help.ubuntu.com/community/BasicChroot
[3] http://www.open.collab.net/consulti

SVNParent authz

2011-07-28 Thread Andy Canfield


I am having a problem with AuthzSVNAccessFile.

Consider the case where I have two repositories, R1 and R2 Some users 
are authorized to examine R1 by going to

http://example.com/svn/R1
Other users are authorized to examine R2 by going to
http://example.com/svn/R2
But everyone should be able to see the list of repositories by going to
http://example.com/svn

I can't get that to work. I am having a problem with the 
mod_dav_svn.conf command:

AuthzSVNAccessFile /Subversion/conf/authz
If I have AuthzSVNAccessFile turned off (commented out), then all users 
can see the contents of all repositories. But if I have 
AuthzSVNAccssFile turned on, then nobody is authorized to see the list 
of repositories via "http://example.com/svn"; because I can't figure out 
how to set authz to give read access to the repository collection but 
limited access to the individual repositories. Here is my closest guess 
for authz -

[groups]
everyone = andy,fred
[/]
@everyone = r
[subdoc:/]
andy = rw
The "[/]" section is the part that is incorrect. How can I give everyone 
read access to "http:///example.com/svn"; without giving them read access 
to "http://example.com/svn/subdoc"; ? Indeed, it seems as if the instant 
I turn on AuthzSVNAccessFile nobody can read "http://example.com/svn"; at 
all.


Thank you for your patience.

Re: disable security hole in svn+ssh?

2011-07-28 Thread Ryan Schmidt

On Jul 28, 2011, at 20:27, Andy Canfield wrote:
> On 07/28/2011 09:48 PM, Geoff Hoffman wrote:
>> You can then detect http protocol with a rewrite rule and redirect to https 
>> using mod_rewrite in either the vhost container or .htaccess file. 
> Where would the .htaccess file be for svn+ssh? There's no directory!

.htaccess is a feature of the Apache web server. It is not applicable to svn or 
svn+ssh access, since that uses svnserve and not Apache.

This is more of an Apache issue, but .htaccess files aren't really recommended 
for production use. Turn them off in your httpd.conf, and put your 
http-to-https redirection rules directly into the httpd.conf.

More directly, the answer to your question of how to prevent someone from 
circumventing https and accessing the server via http, is to simply configure 
the server to not serve the repository on http at all. Put all your 
Subversion-related Apache configuration directives inside an https virtual host 
only.

ServerName www.example.com
SSLEngine on
...

DAV svn
...

Re: disable security hole in svn+ssh?

2011-07-28 Thread Ryan Schmidt

On Jul 28, 2011, at 23:44, Ryan Schmidt wrote:
> On Jul 28, 2011, at 20:27, Andy Canfield wrote:
>> On 07/28/2011 09:48 PM, Geoff Hoffman wrote:
>>> You can then detect http protocol with a rewrite rule and redirect to https 
>>> using mod_rewrite in either the vhost container or .htaccess file. 
>> Where would the .htaccess file be for svn+ssh? There's no directory!
> 
> .htaccess is a feature of the Apache web server. It is not applicable to svn 
> or svn+ssh access, since that uses svnserve and not Apache.

If the question was how to redirect someone from svn to svn+ssh, then that's 
not possible, but again, the solution if you want users to only use encrypted 
access would be to not start an svnserve instance on the server, thus 
preventing anyone from using svn protocol.


> More directly, the answer to your question of how to prevent someone from 
> circumventing https and accessing the server via http, is to simply configure 
> the server to not serve the repository on http at all. Put all your 
> Subversion-related Apache configuration directives inside an https virtual 
> host only.
> 
> 

Of course that port number should have been 443.

RE: SVN Error on Commit!!

2011-07-28 Thread Waseem Bokhari

 Really hard to know what to suggest with so little information.

What version of TortoiseSVN on the client?

>> Its 1.6.x "TortoiseSVN "

 What version of SVN on the server? What OS on the server?
>> We are using Visual SVN Server 2.1.3 Enterprise Edition on Windows 2003
Enterprise Edition of Sever.

What communication method? Can you show us the server configuration files?
>>This Query Doesn't make sense to me :(

Does it happen with every commit and every file? Or only this file? Or only
this once? Or only sometimes?
>>It doesn't happen with every commit and every file rather On specific
Activities like ; On "Show Log" , "Openning Repo Browser" , "Saving a File
from Repo Browser" , on "Commit" SOMETIMES Not everytime.

Can you reproduce the issue at will? What about in a clean repository?

>>> I can't produce this issue by Will.

Does it happen only for this user, or for all users?
>> Ramdom Users.

What if you use a different client program? What about a different client
computer?
 >> Happening on Different computers.

Pls feel free to ask.

-Original Message-
From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com]
Sent: Friday, July 29, 2011 1:13 AM
To: Waseem Bokhari
Cc: users@subversion.apache.org
Subject: Re: SVN Error on Commit!!
Importance: High

On Jul 28, 2011, at 07:34, Waseem Bokhari wrote:

> Greetings!
>I am facing the following error on Commit
in Tortoise SVN:-
>
> Pls Guide.
>
>
> Commit failed (details follow):
> Server sent unexpected return value (500 Internal Server Error) in
response to
> PUT request for
'/svn/nfs-cap-alamthal/!svn/wrk/ae7ebfe8-00e4-1f4b-ab19-6f510deb747e/Release
%20Workspace/Shipment/4.00.002%20Patch%2001/CAP%20WEB/Exe/Templates/Bassic_T
emplate/Local_Images/open-diary-normal.gif'

Really hard to know what to suggest with so little information.

What version of TortoiseSVN on the client? What version of SVN on the
server? What OS on the server?

What communication method? Can you show us the server configuration files?

Does it happen with every commit and every file? Or only this file? Or only
this once? Or only sometimes?

Can you reproduce the issue at will? What about in a clean repository?

Does it happen only for this user, or for all users?

What if you use a different client program? What about a different client
computer?

DISCLAIMER:  This e-mail and any file transmitted with it are confidential and 
intended solely
for the use of the addressee.  If you are not the intended recipient, you are 
hereby advised that
any dissemination, distribution or copy of this email or its attachments is 
strictly prohibited.  If you
have received this email in error, please immediately notify us by return email 
and destroy this email
message and its attachments.  This communication may contain forward-looking 
statements
relating to the development of NetSol Technologies' products and services and 
future operations.
The words "believe," "expect," "anticipate," "intend," variations of such 
words, and similar
expressions, identify forward looking statements, but their absence does not 
mean that the
statement is not forward-looking.  Views and opinions contained herein are 
those of the author of
this email and do not necessarily represent those of NetSol Technologies.  
Statements contained
herein are not guarantees of future performance and are subject to certain 
risks, uncertainties and
assumptions that are difficult to predict. The company will not undertake to 
update any statements
contained herein.

WARNING: The recipient should check this email and any attachment for the 
presence of viruses.
Although the company has taken reasonable precautions to ensure no viruses are 
present in this
email, the company does not accept responsibility for any loss or damage 
arising from the use of
this email or attachment. Note: Please consider the environment before printing 
this e-mail.

Access to the SVNParentPath

2011-07-28 Thread Andy Canfield

That's a wonderful thing about computers. Every time I come up with 
something that is impossible, I figure out a way to do it.


My current test repository server is named "athol". But I can not look 
at "http://athol/svn";; nobody is allowed to see that.


But, as of now, if I point my browser to "http://athol/Subversion";, I 
see this:



 Subversion on Athol


   Repositories

   sample3 
   subdoc 

How? Well, the file /Subversion/GSite/index.php is how:
\n";
echo "\n";
echo "$TITLE\n";
echo "\n";
echo "\n";
echo "$TITLE\n";
echo "Repositories\n";
$SVNParentPath = "/Subversion";
$RepoList = scandir( $SVNParentPath );
foreach ( $RepoList as $RepoName )
{
$TestRepo = $SVNParentPath . "/" . $RepoName . "/hooks" ;
if ( file_exists( $TestRepo ) )
{
echo ""
. $RepoName
, "\n";
}
}
closedir( $DIR );
echo "\n";
echo "\n";
?>

It is, of course, trivlal to use .htpassed to restrict access to this 
web page to people who are supposed to be there, and even if someone can 
bypass that restriction they only get a list of repositories; The 
standard Subversion authz mechanism takes care of access to the 
individual repositories.


It is also possible to extend this page with a form you can use to 
create a new repository. The form would call up a php page that uses the 
system() command to call svnadmin. Ahah! If we move /usr/sbin/svnadmin 
into a directory which is only readable by Apache, that makes it 
difficult for anyone to use svnadmin at all except through this page. 
It's nasty; I love it.


It's compatable; all the standard commands of the form "svn ... 
http://athol/svn/RepoName"; still work as before. That's because access 
to the individual repositories is still handled by Subversion.


Maybe one of those wonderful packages like WebSVN could have done that 
for me, but I haven't got any of them to work yet. This took me an hour 
to get up and running and I can make it do whatever I like.


I am happy! I think I've got it!

Of course, this depends on HTTP or HTTPS access to the production 
server, which we're still working on. But it feels good. In the meantime 
we can live with svn+ssh.


Thank you all very much.

RE: SVNParent authz

2011-07-28 Thread Cooke, Mark

> -Original Message-
> From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] 
> Sent: 29 July 2011 05:14
> To: users@subversion.apache.org
> Subject: SVNParent authz
> 
> I am having a problem with AuthzSVNAccessFile.
> 
> Consider the case where I have two repositories, R1 and R2 Some users 
> are authorized to examine R1 by going to
>  http://example.com/svn/R1
> Other users are authorized to examine R2 by going to
>  http://example.com/svn/R2
> But everyone should be able to see the list of repositories 
> by going to
>  http://example.com/svn
> 
> I can't get that to work. I am having a problem with the 
> mod_dav_svn.conf command:
>  AuthzSVNAccessFile /Subversion/conf/authz
> If I have AuthzSVNAccessFile turned off (commented out), then 
> all users 
> can see the contents of all repositories. But if I have 
> AuthzSVNAccssFile turned on, then nobody is authorized to see 
> the list 
> of repositories via "http://example.com/svn"; because I can't 
> figure out 
> how to set authz to give read access to the repository collection but 
> limited access to the individual repositories. Here is my 
> closest guess 
> for authz -
>  [groups]
>  everyone = andy,fred
>  [/]
>  @everyone = r
>  [subdoc:/]
>  andy = rw
> The "[/]" section is the part that is incorrect. How can I 
> give everyone 
> read access to "http:///example.com/svn"; without giving them 
> read access 
> to "http://example.com/svn/subdoc"; ? Indeed, it seems as if 
> the instant 
> I turn on AuthzSVNAccessFile nobody can read 
> "http://example.com/svn"; at 
> all.
> 
> Thank you for your patience.
> 
There was a bug relating to authz which meant that users had to have
access to the root to see anything, you do not mention which version you
are using?

Note that you can remove permissions as well as grant them, so something
like this should work...

[groups]
everyone = andy,fred

[/]
@everyone = r

[R1:/]
andy = rw
fred = 

[R2:/]
andy = 
fred = rw

If that does not work, can you post the relevant bits of your apache
conf and also which versions and platforms you are on.  For example, I
use the following for our windoze based repos:


DAV svn
SVNParentPath D:/svn/root/
SVNListParentPath On
# restrict access to subversion repository paths...
AuthzForceUsernameCase Lower
AuthzSVNAccessFile D:/path/to/svn-users.txt


~ mark c

SVN Error on Commit!!

FAIL: svnlook_tests.py 11: test 'svnlook * -t'

Re: FAIL: svnlook_tests.py 11: test 'svnlook * -t'

Subversion version 7.0 Beta2 release configure attempt error

Re: Subversion version 7.0 Beta2 release configure attempt error

Re: disable security hole in svn+ssh?

Re: disable security hole in svn+ssh?

Re: disable security hole in svn+ssh?

Re: disable security hole in svn+ssh?

Re: SVN Error on Commit!!

1.7 apr-util --with-expat=builtin configure option

Re: disable security hole in svn+ssh?

Re: disable security hole in svn+ssh?

SVNParent authz

Re: disable security hole in svn+ssh?

Re: disable security hole in svn+ssh?

RE: SVN Error on Commit!!

Access to the SVNParentPath

RE: SVNParent authz

19 matches

Site Navigation

Mail list logo

Footer information