Re: SVN Query about granting access

[Daniel Shahaf]

Geoff Field wrote on Wed, Apr 09, 2014 at 13:58:30 +1000:
>   Do you grant global read/write access to that repository at all?
>   Not sure, about this. Can you please tell me where this param
>   value specified?
> 
> In your Subversion.conf file, there could be a line - most likely
> related to that repository - that says something like:
> 

It's good practice not to refer to files by name but by function since
the name may change among vendors.  In particular, when I saw
"subversion.conf" I thought you were referring to an httpd.conf
directives files.

> Of course, I'm making a lot of assumptions here, but that's what works
> for us.  We've been known to make specific repositories private in our
> configuration by saying (for that repository):
> 
> * =
> 
> I'm not totally convinced it will work, since the individual settings
> seem to override the global ones.  More knowledgeable heads than mine
> might have more of a clue.

There are a number of cases where settings are overridden by other
settings.  For example: when a section name is repeated; when both
[/path] and [foo:/path] exist; when a [/path] stanza contains multiple
LHS tokens that match the authenticated username.  Also there is the
question of whether the correct file is being edited (an easy way to
test this is to insert an intentional syntax error into the file; the
next request on a new connection should then fail with HTTP 500).

(And before someone points out that causing HTTP 500's on a live site is
bad practice: it's bad practice to test an authz file on a live site, so
I'm assuming the edits are done initially in a test setup (maybe a test
 with a different authentication backend).)

My advice is: use 'svnauthz accessof' to debug your authz file.  If you
can't get it to do what you want, make a minimal example that shows the
problem (as few users / paths / repos as possible) and post it here with
an explanation of what semantics (access matrix) you'd like to achieve.

http://subversion.apache.org/docs/release-notes/1.8#svnauthz_accessof

Daniel

Re: SVN Query about granting access

[Daniel Shahaf]

Geoff Field wrote on Tue, Apr 08, 2014 at 09:03:43 +1000:
> > From: Daniel Shahaf
> > Sent: Monday, 7 April 2014 18:13 PM
> > 
> > karthik kg wrote on Mon, Apr 07, 2014 at 17:40:54 +1000:
> > > Repository name - TTN
> > > Location on the server -
> > > 
> > > /apps/bss/SubVersion_Repository/TTN
> > > 
> > > 
> > > I tired editing the 
> > /var/opt/app/SubVersion_Repository/NTT/conf/auth 
> > > file with below parameter for providing read only access to 
> > the TTN repository.
> > > 
> > > 
> > > [repository:/NTT]
> > > 
> > >   d389678 = 'r'
> 
> As well as what Daniel has quite rightly said, it looks like there's a
> space at the start of the line.  I seem to remember another message on
> this list commenting that spaces at the start of the line might not be
> a good idea.

Good point.  Spaces at the start of a line may cause it to be interpreted
as a continuation line.  If this happened in the context of authz rules
(lines ending in = or =r or =rw) it would invariably result in a syntax
error (so all requests to the repositories governed by the authz file
would error with HTTP 500), but in other sections ([groups], [aliases]) or
other files (svnserve.conf, fsfs.conf, ~/.subversion/config, ...) it may
result in a syntactically-valid file that doesn't do what it appears to do.

For example, try this:

# in ~/.subversion/config
[miscellany]
enable-auto-props = yes
[auto-props]
*.t = svn:eol-style=native;
 *.c = svn:keywords=Id;

(Incidentally, this particular example exposes a bug:
)

Daniel

Re: strange E/W200033 (b)locking error/warning when trying to modify a svn 1.8 working copy over SMB share

[Tobias Bading]

Hi,

follow-up regarding my problems with "database is locked" errors when trying
to access a Subversion 1.8 working copy located on an AIX machine 
remotely via

SMB from a GNU/Linux machine:

- A Windows SMB share causes the same errors, so it's not specific to Samba.

- The problem can be circumvented by mounting the SMB share with option
  'nobrl'. From the mount.cifs(8) man page:

nobrl
Do not send byte range lock requests to the server. This is 
necessary

for certain applications that break with cifs style mandatory byte
range locks (and most cifs servers do not yet support requesting
advisory byte range locks).

I'm currently giving the 'nobrl' option in combination with

[working-copy]
exclusive-locking-clients = svn

in ~/.subversion/config a try. So far it seems to work just fine. :-)

Tobias

Re: strange E/W200033 (b)locking error/warning when trying to modify a svn 1.8 working copy over SMB share

[Stefan Sperling]

On Wed, Apr 09, 2014 at 11:46:05AM +0200, Tobias Bading wrote:
> Hi,
> 
> follow-up regarding my problems with "database is locked" errors when trying
> to access a Subversion 1.8 working copy located on an AIX machine remotely
> via
> SMB from a GNU/Linux machine:
> 
> - A Windows SMB share causes the same errors, so it's not specific to Samba.
> 
> - The problem can be circumvented by mounting the SMB share with option
>   'nobrl'. From the mount.cifs(8) man page:
> 
> nobrl
> Do not send byte range lock requests to the server. This is
> necessary
> for certain applications that break with cifs style mandatory byte
> range locks (and most cifs servers do not yet support requesting
> advisory byte range locks).
> 
> I'm currently giving the 'nobrl' option in combination with
> 
> [working-copy]
> exclusive-locking-clients = svn
> 
> in ~/.subversion/config a try. So far it seems to work just fine. :-)
> 
> Tobias

Hi Tobias,

That's very nice!

Would be able to prepare a patch against our FAQ to document this?
Perhaps this entry could be extended:
http://subversion.apache.org/faq.html#nfs

Source code of the website is here:
http://svn.apache.org/repos/asf/subversion/site/publish/

Re: strange E/W200033 (b)locking error/warning when trying to modify a svn 1.8 working copy over SMB share

[Tobias Bading]

On 09.04.2014 12:19, Stefan Sperling wrote:
> On Wed, Apr 09, 2014 at 11:46:05AM +0200, Tobias Bading wrote:
>> Hi,
>>
>> follow-up regarding my problems with "database is locked" errors 
when trying
>> to access a Subversion 1.8 working copy located on an AIX machine 
remotely

>> via SMB from a GNU/Linux machine:
>>
>> - A Windows SMB share causes the same errors, so it's not specific 
to Samba.

>>
>> - The problem can be circumvented by mounting the SMB share with option
>>   'nobrl'. From the mount.cifs(8) man page:
>>
>> nobrl
>> Do not send byte range lock requests to the server. This is 
necessary
>> for certain applications that break with cifs style 
mandatory byte

>> range locks (and most cifs servers do not yet support requesting
>> advisory byte range locks).
>>
>> I'm currently giving the 'nobrl' option in combination with
>>
>> [working-copy]
>> exclusive-locking-clients = svn
>>
>> in ~/.subversion/config a try. So far it seems to work just fine. :-)
>>
>> Tobias
>
> Hi Tobias,
>
> That's very nice!
>
> Would be able to prepare a patch against our FAQ to document this?
> Perhaps this entry could be extended:
> http://subversion.apache.org/faq.html#nfs
>
> Source code of the website is here:
> http://svn.apache.org/repos/asf/subversion/site/publish/

Well, so far I didn't do much testing. Basic things like Emacs running a
"svn resolved" when the last conflict marker is gone works, as does a "svn
update" from the Linux machine. But it might be possible that I've managed
to outmaneuver SQLite's locking mechanism(s) entirely. A "strace svn update"
shows that calls like

fcntl(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=1073741826, 
len=510}) = 0


work now, which is to be expected of course if the 'nobrl' option basically
converted these calls into no-ops. I had hoped though that the
'exclusive-locking-clients = svn' option would cause svn to lock the wc.db
file completely, but I can't see anything like that in the trace, just a few
byte-range locks via fcntl(F_SETLK). So my guess would be that at the
moment, svn commands running on the Linux machine don't lock the working
copy on the AIX machine at all. That's fine for my use cases, but not
something I would recommend to others in general.

SVN client SSL CRL configuration

[mskala]

I'm not subscribed to the list and would appreciate a cc: on any replies.

I run a Subversion server accessible through Apache HTTPS, and several
clients that connect to it, all under Linux, and I run my own CA
(certificate authority) to issue SSL certificates to all parties.  When I
set it up, I made no provision for issuing and distributing CRLs
(certificate revocation lists), not expecting that to ever be a relevant
issue.  My server was "heartbleed"-vulnerable and has now been patched for
that; but it appears that as a result of possible past compromise I have
to issue new certificates for all the parties and revoke the old ones.

My main question is:  how do I get the Subversion command-line client to
read a CRL?  The ssl-authority-files configuration setting lets me specify
my CA's root certificate in a file; is there a similar setting for the
CRL?  I would prefer to distribute the CRL as a file (instead of a URL to
be checked automatically); is that possible?  Or is it absolutely
necessary to post the CRL online somewhere and specify its URL in the root
certificate (which will require constructing a new root certificate and a
bunch of scripts to periodically re-issue and re-post the file).  If it's
going to necessitate changes to the root certificate and frequent ongoing
maintenance, I might be better off just re-doing the entire public key
infrastructure from scratch, annoying as that will be.

Note I am specifically asking about the Subversion command-line client
running under Linux.  I already know how to configure Apache to read the
CRL on the server side.  All I've been able to find online regarding
*client-side* Subversion CRL use is Windows-specific.
-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

Re: svn2cvsgraph, how to best handle merges?

[Henrik Carlqvist]

On Wed, 26 Mar 2014 19:41:38 +
Philip Martin  wrote:

> Henrik Carlqvist  writes:
> > Would people hosting public svn repositories think that it would be
> > nice if some people using my tool would make one svn connection for
> > each revision in the repository?
> 
> It's a user problem as well since making a request per revision doesn't
> scale well and will be very slow for large projects.

As the merge information you get from "svn log -g" is somewhat recursive
it seems as if time grows exponentially with the number of revisions (or
maybe rather with the number of merges).

However, my own test version of svn2cvsgraph which calls svn once for each
revision does a pclose on the svn call after reading the first log entry
and the second log entry (which might be a merge). With such a solution
time grows linear with the number of revisions, but svn older than 1.7
will give some "svn: Write error: Broken pipe" to stderr.

I did a benchmark comparing a box running Slackware 14.1 with svn 1.7.16
and another box running Slackware 13.1 with svn 1.6.16. On these machines
I tested 3 version of svn2cvsgraph:

svn2cvsgraph 1.2: makes a single call to "svn log -q -g" on the subversion
  repository root.

svn2cvsgraph 2.0: makes one call to "svn log -q -g" for each branch 
  (and trunk)

svn2cvsgraph 2.1beta: makes one call to "svn log -q -g" for each revision,
  the call is aborted with pclose to avoid wasting
  time on redundant information.

The benchmarks were run on a test subversion repository which was read
from a 2.9 GB big subversion dump file of an actual project repository.
The repository contains 13570 revisions and 160 branches. 206 merges has
been logged into the repository since the repository was upgraded to
version 1.5 of subversion. The test repository was accessed as file:/// on
an NFS server. Times were measured with the /usr/bin/time command.

These are the results:

subversion   svn2cvsgraph   time  result
1.7.161.26:13.70elapsed 17%CPUNo merges found
1.7.162.1beta7:20.73elapsed 55%CPUAll merges found
1.7.162.0   13:49.48elapsed 45%CPU23 merges lost

1.6.162.1beta   52:53.63elapsed 81%CPUAll merges found
1.6.161.2   134:55:22elapsed 41%CPU   All merges found
1.6.162.0   135:14:04elapsed 41%CPU   All merges found

Subversion 1.7.16 seems a lot faster than 1.6.16. Even though the tests
were run on different machines and the Slackware 14.1 machines is slightly
faster than the Slackware 13.1 machine I think that most of the difference
is thanks to that 1.7.16 gives less recursive merge information to wade
through.

No merges are found when only doing "svn log -q -g" on the repository root
with version 1.7.16. This is expected behavior as the behavior of "svn log
-g" changed with version 1.6.17.

23 merges were lost with "svn log -q -g" on every branch with 1.7.16, this
is most likely because of issue 4477.

Doing "svn log -q -g" for each revision and abort the output with pclose
is the fastest way to get correct results for both version 1.6.16 and
1.7.16. However, this is assuming that the repository is accessed with
file://. Previously I have instead been using svn+ssh:// with svn 1.6.16
and with one call for each branch or only for the repository root that
takes about 24 hours (compared with about 135 hours above). However using
svn+ssh:// instead of file:// when doing one call for each revision would
be a lot slower.

regards Henrik

Re: SVN client SSL CRL configuration

[Ben Reser]

On 4/9/14, 8:56 AM, msk...@ansuz.sooke.bc.ca wrote:
> I'm not subscribed to the list and would appreciate a cc: on any replies.
> 
> I run a Subversion server accessible through Apache HTTPS, and several
> clients that connect to it, all under Linux, and I run my own CA
> (certificate authority) to issue SSL certificates to all parties.  When I
> set it up, I made no provision for issuing and distributing CRLs
> (certificate revocation lists), not expecting that to ever be a relevant
> issue.  My server was "heartbleed"-vulnerable and has now been patched for
> that; but it appears that as a result of possible past compromise I have
> to issue new certificates for all the parties and revoke the old ones.
> 
> My main question is:  how do I get the Subversion command-line client to
> read a CRL?  The ssl-authority-files configuration setting lets me specify
> my CA's root certificate in a file; is there a similar setting for the
> CRL?  I would prefer to distribute the CRL as a file (instead of a URL to
> be checked automatically); is that possible?  Or is it absolutely
> necessary to post the CRL online somewhere and specify its URL in the root
> certificate (which will require constructing a new root certificate and a
> bunch of scripts to periodically re-issue and re-post the file).  If it's
> going to necessitate changes to the root certificate and frequent ongoing
> maintenance, I might be better off just re-doing the entire public key
> infrastructure from scratch, annoying as that will be.
> 
> Note I am specifically asking about the Subversion command-line client
> running under Linux.  I already know how to configure Apache to read the
> CRL on the server side.  All I've been able to find online regarding
> *client-side* Subversion CRL use is Windows-specific.

The answer unfortunately is that currently we don't support CRLs.  However, we
may have a workaround.  We're investigating currently and will follow up with
more info soon.