RE: lock tree or branch - quick question

[Thomas Hemmer]

Have a look at
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html.

If you are in need of a conditional commit access control mechanism, you
should consider using a start-commit hook - see
http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.start-commit.html for
details.


Best regards,

Thomas


-Original Message-
From: Z W [mailto:mpc8...@gmail.com] 
Sent: Tuesday, February 12, 2013 6:49 PM
To: users@subversion.apache.org
Subject: lock tree or branch - quick question

Hi All

We like to stop commits to a certain tree or branch.
Is there a way to do that on SVN ?
Is this an svn admin command ?

Thanks


GO Engineering GmbH - Stolzenbergstr. 13/IV - 76532 Baden-Baden
Geschäftsführer:
Helmut Gerstner, Dipl.-Ing. (FH)
Ralf Wörner, Dipl.-Ing. (FH)
Registergericht: Mannheim HRB 201811

Path based authz - problem with rules for moved/deleted content

[Schmidt, Michael]

Hello,

In my research institute we are using SVN with path based access control via 
mod_svn_authz. Now I am facing the problem that we had some code within our 
trunk folder which is only accessible to a subgroup of developers. In order to 
protect it from unauthorized access we added an access restriction for that 
code. Unfortunately, we learned the hard way that this is not really a good 
thing to do since it prevents all other users from being able to branch the 
trunk folder. Obviously, even after moving the "confidential" code to a 
different location we still have to keep the old authz rules in place in order 
to prevent leaking the code to unauthorized developers through the history 
access. Unfortunately, the existence of these rules continues to prevent 
non-privileged developers rules from being allowed to copy the trunk, although 
no content in the trunk is actually matched by the rules anymore. Currently, 
the only solution to this problem that I see would be to move the (now cleaned) 
trunk to a new location for which no such conflicting rules exist. However, we 
would rather use this as a last resort and prefer a solution that let's us 
continue to use the current structure. This is especially true since it could 
happen that somebody again commits confidential information to the trunk which 
then needs to be protected when we notice it.

Is anybody aware of a good way to deal with this kind of issues? Or is there 
any development going on to support such things in future versions, e.g. by 
allowing to configure revision ranges for which rules apply? I would appreciate 
any helpful hints on how one could deal with this topic now or in foreseeable 
future.

Best regards, Michael


--
Michael Schmidt
Fraunhofer MEVIS
Institute for Medical Image Computing
Universitaetsallee 29
28359 Bremen

Phone: +49-421-218-59273
Fax:   +49-421-218-98-59273

Email: 
michael.schm...@mevis.fraunhofer.de
Web:   http://www.mevis.fraunhofer.de
--

Bug or unexpected WC state?

[Hans Meine]

Hi,

I am seeing some strange behavior I cannot explain at all, but I am not sure 
whether it is a bug or some strange state of my working copy which I do not 
know how to inspect yet.

After some "svn switch"ing, there is a directory missing from my working copy 
now, but svn status says I am clean, and svn revert does not bring it back.
"svn st" displays nothing, "svn revert --depth=infinity ." does nothing, but 
although e.g. "svn list" shows four subdirectories (as expected), only three 
of them are in my working copy.

Which commands should I try to determine why the folder appears to be lost?
For instance, I know it could be switched to god-knows-which branch which does 
not contain the folder, but then svn status should show it with an "S", no? 
(Maybe only for still-existing paths?)  How could I quickly revert such a 
switch (I already tried a switch in a parent directory)?

Shall I file a bug about it?

ATM, I think I could even still describe how I got there, since I still have 
the terminal open with the commands that led to this state.

Best regards,
  Hans

Re: Bug or unexpected WC state?

[Hans Meine]

Am Mittwoch, 13. Februar 2013, 11:45:34 schrieb Hans Meine:
> After some "svn switch"ing, there is a directory missing from my working
> copy now, but svn status says I am clean, and svn revert does not bring it
> back. "svn st" displays nothing, "svn revert --depth=infinity ." does
> nothing, but although e.g. "svn list" shows four subdirectories (as
> expected), only three of them are in my working copy.

OK, the fix was not too difficult, once you know what to try: "svn up 
missing_folder" brought it back.

But the main question still holds:
> Which commands should I try to determine why the folder appears to be lost?

Ignoring the (interesting) question how I got into this state, I obviously had 
a sticky revision tagged to the missing directory.

The question is now: How can I detect this when looking at a working 
directory?

Ideally, I would like to recursively scan my working directory for any 
deviations from a clean checkout.  Looks like a job for "svn status", but I do 
not see an option for displaying this.  (I did try "svn status -v" before.)

Best regards
  Hans

Re: Bug or unexpected WC state?

[Stefan Sperling]

On Wed, Feb 13, 2013 at 11:45:34AM +0100, Hans Meine wrote:
> Hi,
> 
> I am seeing some strange behavior I cannot explain at all, but I am not sure 
> whether it is a bug or some strange state of my working copy which I do not 
> know how to inspect yet.
> 
> After some "svn switch"ing, there is a directory missing from my working copy 
> now, but svn status says I am clean, and svn revert does not bring it back.
> "svn st" displays nothing, "svn revert --depth=infinity ." does nothing, but 
> although e.g. "svn list" shows four subdirectories (as expected), only three 
> of them are in my working copy.
> 
> Which commands should I try to determine why the folder appears to be lost?
> For instance, I know it could be switched to god-knows-which branch which 
> does 
> not contain the folder, but then svn status should show it with an "S", no? 
> (Maybe only for still-existing paths?)  How could I quickly revert such a 
> switch (I already tried a switch in a parent directory)?
> 
> Shall I file a bug about it?

My guess is that you're seeing this bug:
http://subversion.tigris.org/issues/show_bug.cgi?id=4295
A fix has been nominated for the 1.7.9 release.

Re: Bug or unexpected WC state?

[Hans Meine]

Am Mittwoch, 13. Februar 2013, 12:34:37 schrieb Stefan Sperling:
> On Wed, Feb 13, 2013 at 11:45:34AM +0100, Hans Meine wrote:
> > I am seeing some strange behavior I cannot explain at all, but I am not
> > sure whether it is a bug or some strange state of my working copy which I
> > do not know how to inspect yet.
> > …
> > Shall I file a bug about it?
> 
> My guess is that you're seeing this bug:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4295
> A fix has been nominated for the 1.7.9 release.

That's exactly what happened to me, glad to see it's fixed.

The question whether there should be some output e.g. in "svn status -v" or a 
--show-sticky-revisions (please rename as appropriate) option to status 
remains.

Thanks,
  Hans

Re: Path based authz - problem with rules for moved/deleted content

[Branko Čibej]

On 13.02.2013 10:30, Schmidt, Michael wrote:
>
> Hello,
>
>  
>
> In my research institute we are using SVN with path based access
> control via mod_svn_authz. Now I am facing the problem that we had
> some code within our trunk folder which is only accessible to a
> subgroup of developers. In order to protect it from unauthorized
> access we added an access restriction for that code. Unfortunately, we
> learned the hard way that this is not really a good thing to do since
> it prevents all other users from being able to branch the trunk
> folder. Obviously, even after moving the “confidential” code to a
> different location we still have to keep the old authz rules in place
> in order to prevent leaking the code to unauthorized developers
> through the history access. Unfortunately, the existence of these
> rules continues to prevent non-privileged developers rules from being
> allowed to copy the trunk, although no content in the trunk is
> actually matched by the rules anymore. Currently, the only solution to
> this problem that I see would be to move the (now cleaned) trunk to a
> new location for which no such conflicting rules exist. However, we
> would rather use this as a last resort and prefer a solution that
> let’s us continue to use the current structure. This is especially
> true since it could happen that somebody again commits confidential
> information to the trunk which then needs to be protected when we
> notice it.
>
>  
>
> Is anybody aware of a good way to deal with this kind of issues? Or is
> there any development going on to support such things in future
> versions, e.g. by allowing to configure revision ranges for which
> rules apply? I would appreciate any helpful hints on how one could
> deal with this topic now or in foreseeable future.
>

There's a long-standing idea for implementing access control in the
repository itself, i.e., not relying on an external access configuration
file. Applying ACLs to certain (historical) revision ranges is part of
that idea.

I can't promise anything about when it'll be available, but some of us
are hoping to at least write a design for that in the near future.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

AW: Could not read chunk size: connection was closed by server on Windows 7

[Michael Zender]

> -Ursprüngliche Nachricht-
> Von: Mark Phippard [mailto:markp...@gmail.com]
> Gesendet: Freitag, 8. Februar 2013 18:34
> An: Michael Zender
> Cc: users@subversion.apache.org
> Betreff: Re: Could not read chunk size: connection was closed by
> server on Windows 7
> 
> On Fri, Feb 8, 2013 at 10:28 AM, Michael Zender
>  wrote:
> 
> > I finally solved my problem and wanted to share my solution with
> you.
> 
> Thanks for letting us know.
> 
> > It turned out, that Kaspersky Endpoint Security 8 and its Web-Anti-
> Virus
> > feature in particular were causing this problem to show up. We
> solved it
> > by defining a rule that excludes our subversion servers from the
> > Web-Anti-Virus service. The Windows XP still had Kaspersky 6
> installed
> > which does not have the Web-Anti-Virus feature.
> 
> I was thinking on this overnight, and believe it or not I was going to
> propose you look in this general direction.
> 
> > I still don't know what exactly the problem is because in my
> opinion,
> > the anti virus software should act in a completely transparent
> manner
> > but anyways, it's working now, so I don't bother any more!
> 
> If you look at the FAQ and remove some of the specifics, more
> generally what it is saying is that while the client is doing some
> work the connection to the server is closed in a manner that the
> client is not expecting it.  So the error manifests to the client as a
> chunk delimiter error when the data it is reading disappears.  The FAQ
> describes one scenario that caused this, the server ending the
> connection.
> 
> These Windows anti-virus solutions operate at a low level so they can
> intercept and monitor your TCP/IP traffic.  I would guess that either
> Subversion's pattern of HTTP requests looked unusual or perhaps even
> the content in one of your files.  My guess is that when these tools
> sense a problem they do not try to be graceful about it.  It probably
> just kills the connection.  After all if it were a virus or trojan
> horse on your computer it does not want to make it easier for the
> malicious code to recover.  So most likely when it senses a problem it
> closed the connection and that manifested itself the same as the
> server timeout.
> 
> One thing that might be helpful is to look into what kind of logging
> the tool provides. It would be nice if they log some forensic data
> about what caused them to do this.  Maybe that information can go back
> to Kapersky to make the tool not do this.  Or maybe it is just a bug
> in their tool where they cannot handle all of the requests and how
> fast they are being made.  I suspect a SVN client drives HTTP traffic
> a lot differently than a typical web browser loading a page does.
> 
> > Thanks again to Mark for his reply, it definitely made me
> investigate in
> > the right direction.
> 
> You are welcome and thanks for sharing the information back.  Do you
> have any suggestions on how this FAQ could be improved to add this
> information?
> 
> --
> Thanks
> 
> Mark Phippard
> http://markphip.blogspot.com/

Hi Mark,

thank you for your detailed explanation.

You are right, that anti-virus software would just close a suspicious
connection and not care about the aftermath. I did not even remotely
think of the possibility that maybe the anti-virus software is actually
detecting a virus :)!

So I checked with our infrastructure department but the log files for my
machine don't report anything in that direction. I also don't think that
this is the case because I also observed the problem with an artificial
repository containing only generated files with random content.

Regarding the FAQ, I think you could add to the section that you
mentioned earlier (
http://subversion.apache.org/faq.html#secure-connection-truncated) that
the problem may also originate not only from the server- but also from
the client side and explicitly mention anti-virus software as a possible
source of the problem.

Thanks again!

Best regards

Michael

Re: lock tree or branch - quick question

[C. Michael Pilato]

On 02/13/2013 03:04 AM, Thomas Hemmer wrote:
> Have a look at
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html.
> 
> If you are in need of a conditional commit access control mechanism, you
> should consider using a start-commit hook - see
> http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.start-commit.html for
> details.

Those are some good doc pointers, but be aware that the start-commit hook
lacks the context to perform path-based conditional commit access.  It's not
until the pre-commit hook phase that the server knows which paths were
modified as part of the commit.  So, yes, you can do this conditionally from
hooks, but use pre-commit rather than start-commit to do so.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: Discrepancies in svn mirror created with svnsync

[Marius Gedminas]

On Tue, Feb 12, 2013 at 06:54:14PM +0100, Stefan Sperling wrote:
> On Tue, Feb 12, 2013 at 05:18:01PM +0200, Marius Gedminas wrote:
> > Anyway, this takes care of prevention.  What about recovery?  Can I fix
> > the three missing revisions manually somehow?
> 
> If you can obtain the original revision files from the master
> repository, you can try dropping them into the slave repository as-is.
> That should work, provided the revs are valid on the master.

I don't have shell (or file) access to the original server.

> > Or at least truncate my
> > mirror's history to that point so that I could run svnsync to get just
> > the last month and a half, instead of re-creating the mirror from
> > scratch?
> 
> It's possible to reset the repository to some revision rN, yes.
> 
> The official way of doing this is to dump the repository from r0
> to rN (using svnadmin dump) and loading this dump file into a freshly
> created repository (svnadmin load).
> Since you're creating an svnsync mirror you should probably run
> 'svnsync init' before loading the dump file, and after loading adjust
> the svn:sync-last-merged-rev revision property on r0 to say 'rN'.

Thanks, this worked (after a false start where I assumed svnadmin dump
-rN:M would be a half-open interval like it is for svn log -rN:M; in the
end I wasted an hour and had to repeat the dump & load):

  $ mv zope-mirror zope-mirror.BROKEN
  $ svnadmin create zope-mirror
  $ svnadmin setuuid zope-mirror 62d5b8a3-27da-0310-9561-8e5933582275
  $ cp zope-mirror.BROKEN/hooks/pre-revprop-change zope-mirror/hooks/
  $ svnsync init file:///$PWD/zope-mirror svn://svn.zope.org/repos/main/
  $ svnadmin dump zope-mirror.BROKEN -r0:129020 > DUMP
  $ svnadmin load zope-mirror --bypass-prop-validation -q < DUMP
  $ svnadmin setrevprop zope-mirror -r0 svn:sync-last-merged-rev <(svnlook 
youngest zope-mirror)
  $ svnlook propget --revprop zope-mirror -r0 svn:sync-last-merged-rev
  129320

But then I ran svnsync again and it gave me broken revisions again:

  $ svnsync sync file:///$PWD/zope-mirror
  $ svnlook author -r 129030 zope-mirror/ | wc -c
  1

And then I noticed that r129027 also became broken in this new mirror,
but was fine in the old one:

  $ svnlook author -r 129027 zope-mirror/ | wc -c
  1
  $ svnlook author -r 129027 zope-mirror.BROKEN/ | wc -c
  4

I was doing this with a copy of the broken mirror on my laptop, which
has svnsync version 1.7.5 (r1336830).

I guess this answers your question from upthread:

> It would be interesting to know if this problem also appears with 
> svnsync from 1.7.

Sadly, yes.

Marius Gedminas
-- 
No proper program contains an indication which as an operator-applied
occurrence identifies an operator-defining occurrence which as an
indication-applied occurrence identifies an indication-defining occurrence
different from the one identified by the given indication as an
indication-applied occurrence.
-- ALGOL 68 Report


signature.asc
Description: Digital signature

Re: Discrepancies in svn mirror created with svnsync

[Stefan Sperling]

On Wed, Feb 13, 2013 at 09:19:13PM +0200, Marius Gedminas wrote:
> But then I ran svnsync again and it gave me broken revisions again:
> 
>   $ svnsync sync file:///$PWD/zope-mirror
>   $ svnlook author -r 129030 zope-mirror/ | wc -c
>   1
> 
> And then I noticed that r129027 also became broken in this new mirror,
> but was fine in the old one:
> 
>   $ svnlook author -r 129027 zope-mirror/ | wc -c
>   1
>   $ svnlook author -r 129027 zope-mirror.BROKEN/ | wc -c
>   4
> 
> I was doing this with a copy of the broken mirror on my laptop, which
> has svnsync version 1.7.5 (r1336830).
> 
> I guess this answers your question from upthread:
> 
> > It would be interesting to know if this problem also appears with 
> > svnsync from 1.7.
> 
> Sadly, yes.

It is possible that authz rules prohibit access to the path affected
by the revision. In which case svnsync would silently omit that path.

Re: Discrepancies in svn mirror created with svnsync

[Philip Martin]

Stefan Sperling  writes:

> It is possible that authz rules prohibit access to the path affected
> by the revision. In which case svnsync would silently omit that path.

$ svn log -vqr129027 svn://svn.zope.org/repos/main/

r129027 | (no author) | (no date)


That looks like a revision filtered by authz.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: Discrepancies in svn mirror created with svnsync

[Marius Gedminas]

On Wed, Feb 13, 2013 at 08:32:35PM +, Philip Martin wrote:
> Stefan Sperling  writes:
> 
> > It is possible that authz rules prohibit access to the path affected
> > by the revision. In which case svnsync would silently omit that path.
> 
> $ svn log -vqr129027 svn://svn.zope.org/repos/main/
> 
> r129027 | (no author) | (no date)
> 
> 
> That looks like a revision filtered by authz.

Oh, interesting.  I was checking with the web frontend where that
revision looks normal: http://svn.zope.org/?rev=129027&view=rev

When I try a checkout (with my ssh key), it fails with

  $ svn co svn+ssh://svn.zope.org/repos/main/2github/trunk 2github
  svn: E170001: Authorization failed

which pretty much seals the case, I guess.


I'm a bit disconcerned about lack of any warning when svnsync produces a
mirror that is different from the original repository.  And also curious
how original first mirror managed to get a copy of that revision, but
not of r129030-129032.  Authz rules added after the fact, probably.


I guess I'll have to patch svn-all-fast-export not to segfault when it
encounters such empty revisions.  (Unfortunately attempting to exclude
them by revision number is not enough.)

Marius Gedminas
-- 
I never got into Linux. I swear to God, it's only lack of time. I'm past the
years of my life where I can really dig into something like running a Linux
system. I'm very sympathetic to the whole idea; Linux people always think the
way I want to think.
-- Steve Wozniak


signature.asc
Description: Digital signature