Re: ssh+svn vs. bash security bug?
On Wed, Sep 24, 2014 at 07:30:57PM -0400, Nico Kadel-Garcia wrote: > Setting up a chroot for Subversion for just this purpose gets... > potentially adventuresome. The maintainers of OpenSSH have generically > refused to support chroot changes, so it's a bit awkward to even set > up. Various folks have published patches or integration kits to > support genuine chroot cages: heck, even I used to publish patches for > OpenSSH to provide them. I have to admit that while I did successfully chroot svnserve with svn:// once, I've never tried to chroot svn+ssh:// But I'd be surprised if OpenSSH was making this difficult. The ChrootDirectory configuration option of OpenSSH won't do? If so, why not? Upgrading bash is a better solution to this particular problem, of course, but using a chroot containing the minimum components could still be a good idea in general.
RE: Data Commit Limit in SVN V1.8.9 !!!
I'd also question just exactly what it is that you're storing in Subversion that is consuming 4-5Gb. Remember - once something has been committed to a Subversion repository it's there *forever*. If you're performing 4-5Gb commits each time I can see your filesystem getting very big, very quickly. David. -- David Grierson – SDLC Tools Specialist Sky Broadcasting - Customer Business Systems - SDLC Tools Tel: +44 1506 325100 / Email: david.grier...@bskyb.com / Chatter: CBS SDLC Tools Watermark Building, Alba Campus, Livingston, EH54 7HH > -Original Message- > From: Andreas Stieger [mailto:andreas.stie...@gmx.de] > Sent: 24 September 2014 22:57 > To: users@subversion.apache.org > Subject: Re: Data Commit Limit in SVN V1.8.9 !!! > > Hi, > > On 24/09/14 22:48, Mohsin Abbas wrote: > > My data size was around 4 plus GB. My commit was failed before 1 GB. Is > > there any limit in SVN for not commit data larger then 1 GB ? Can I > > commit 4 or 5 GB data in one commit ? > > This is not in Apache Subversion itself but serf. You could apply the > patch below, or use a different transport. > https://code.google.com/p/serf/issues/detail?id=152 > https://code.google.com/p/serf/source/detail?r=2419 > > Andreas Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
RE: ssh+svn vs. bash security bug?
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 25 september 2014 10:09 > To: Nico Kadel-Garcia > Cc: Les Mikesell; users > Subject: Re: ssh+svn vs. bash security bug? > > On Wed, Sep 24, 2014 at 07:30:57PM -0400, Nico Kadel-Garcia wrote: > > Setting up a chroot for Subversion for just this purpose gets... > > potentially adventuresome. The maintainers of OpenSSH have generically > > refused to support chroot changes, so it's a bit awkward to even set > > up. Various folks have published patches or integration kits to > > support genuine chroot cages: heck, even I used to publish patches for > > OpenSSH to provide them. > > I have to admit that while I did successfully chroot svnserve with > svn:// once, I've never tried to chroot svn+ssh:// > > But I'd be surprised if OpenSSH was making this difficult. > The ChrootDirectory configuration option of OpenSSH won't do? > If so, why not? > > Upgrading bash is a better solution to this particular problem, > of course, but using a chroot containing the minimum components > could still be a good idea in general. Also switching these users to a shell with far less features than bash might be an even better solution. If the users are only allowed to use 'svnserve' they don't need all the features of a shell... Bert
Re: ssh+svn vs. bash security bug?
On Thu, Sep 25, 2014 at 4:08 AM, Stefan Sperling wrote: > On Wed, Sep 24, 2014 at 07:30:57PM -0400, Nico Kadel-Garcia wrote: >> Setting up a chroot for Subversion for just this purpose gets... >> potentially adventuresome. The maintainers of OpenSSH have generically >> refused to support chroot changes, so it's a bit awkward to even set >> up. Various folks have published patches or integration kits to >> support genuine chroot cages: heck, even I used to publish patches for >> OpenSSH to provide them. > > I have to admit that while I did successfully chroot svnserve with > svn:// once, I've never tried to chroot svn+ssh:// > > But I'd be surprised if OpenSSH was making this difficult. > The ChrootDirectory configuration option of OpenSSH won't do? > If so, why not? They used to reject it wholesale. I think due to demand, they've lightened up in various ways. OpenSSH 6, which I've not personally gotten to use in production, allegedly is the most graceful about it. But this is what I run into with setting up sftp or ssh based cages with OpenSSH 5 and ChrootDirectory: " Specifies a path to chroot(2) to after authentication. This path, and all its components, must be root-owned directories that are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user’s home directory. That means that if you "chroot to the the user's home direcotory" for things like sftp or scp access, their home directory must be owned by root, and they effectively cannot create or delete directories at the top of their own home directory. This leads to. interesting confusion. In theory, for svn+ssh, it's more workable. The top level directory needs be owned by root, and the repository and other components can be gracefully in subdirectories. > Upgrading bash is a better solution to this particular problem, > of course, but using a chroot containing the minimum components > could still be a good idea in general. Now that RHEL 7 is out with much more recentn OpenSSH, I'll see if I can find some cycles to investigate chrooting svn+ssh with that. I suspect I'll be be cheating like hell and using "bind" mounts of "/usr", which is fairly loathsome to insert into a restrecticted chroot cage, but potentially fast and effective.
Re: ssh+svn vs. bash security bug?
On Thu, Sep 25, 2014 at 5:25 AM, Bert Huijben wrote: > > >> -Original Message- >> From: Stefan Sperling [mailto:s...@elego.de] >> Sent: donderdag 25 september 2014 10:09 >> To: Nico Kadel-Garcia >> Cc: Les Mikesell; users >> Subject: Re: ssh+svn vs. bash security bug? >> >> On Wed, Sep 24, 2014 at 07:30:57PM -0400, Nico Kadel-Garcia wrote: >> > Setting up a chroot for Subversion for just this purpose gets... >> > potentially adventuresome. The maintainers of OpenSSH have generically >> > refused to support chroot changes, so it's a bit awkward to even set >> > up. Various folks have published patches or integration kits to >> > support genuine chroot cages: heck, even I used to publish patches for >> > OpenSSH to provide them. >> >> I have to admit that while I did successfully chroot svnserve with >> svn:// once, I've never tried to chroot svn+ssh:// >> >> But I'd be surprised if OpenSSH was making this difficult. >> The ChrootDirectory configuration option of OpenSSH won't do? >> If so, why not? >> >> Upgrading bash is a better solution to this particular problem, >> of course, but using a chroot containing the minimum components >> could still be a good idea in general. > > Also switching these users to a shell with far less features than bash might > be an even better solution. > > If the users are only allowed to use 'svnserve' they don't need all the > features of a shell... Unfortunately for this security issue, bash is the default for many systems. Even "/bin/sh" is often a symlink to "/bin/bash" these days. , And changing the shell of the user that accepts the incoming SSH connections is... interestingly prone to problems if done in a dead rush.
Re: Data Commit Limit in SVN V1.8.9 !!!
Andreas Stieger writes: > Hi, > > On 24/09/14 22:48, Mohsin Abbas wrote: >> My data size was around 4 plus GB. My commit was failed before 1 GB. Is >> there any limit in SVN for not commit data larger then 1 GB ? Can I >> commit 4 or 5 GB data in one commit ? > > This is not in Apache Subversion itself but serf. You could apply the > patch below, or use a different transport. > https://code.google.com/p/serf/issues/detail?id=152 > https://code.google.com/p/serf/source/detail?r=2419 That bug affects checkout/update, does it affect commit as well? Subversion doesn't deliberately limit the size of commits. However an Apache server can be configured to limit the size of HTTP requests, and hook scripts can be written to reject large commits. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Data Commit Limit in SVN V1.8.9 !!! [Urgent]
Team, please help me in this regard i am waiting for your respose. mohsin On 9/25/14, Mohsin Abbas wrote: > Hi All, > > I have problem while committing data in SVN Repository . My data size was > around 4 plus GB. My commit was failed before 1 GB. Is there any limit in > SVN for not commit data larger then 1 GB ? Can I commit 4 or 5 GB data in > one commit ? Please suggest > > > Regards > Mohsin >
Local Repo
Greetings I'm trying to set up a local repository for my schoolwork. The book doesn't seem to have many examples with this type of setup, so i seem to be stumbling a bit. First off, this part seemed to go okeh: $ sudo svnadmin create /usr/local/svn/repos But then this bit doesn't: $ sudo svn import -m "initial import" cashier.cpp file:usr/local/svn/repos Password: svn: E150002: Path 'file:///usr/local/svn/repos' already exists How should i be going about this? sent from Mountain Lion
Re: Local Repo
First, I wouldn't run svn as root like you are with 'sudo'. Instead, change the ownership of your repo so that you have write access. Your command was trying to import 'cashier.cpp' into the repository as the name 'repos'. You need to do this instead: svn import -m "initial import" cashier.cpp file:usr/local/svn/repos/cashier.cpp Import is usually used to bring a whole tree of files into a repository in one shot. Import does not create a working copy, so you will need to subsequently check out to begin using svn to track changes to your file. On Sep 25, 2014, at 8:41 AM, David Lowe wrote: > Greetings > > I'm trying to set up a local repository for my schoolwork. The book > doesn't seem to have many examples with this type of setup, so i seem to be > stumbling a bit. First off, this part seemed to go okeh: > > $ sudo svnadmin create /usr/local/svn/repos > > But then this bit doesn't: > > $ sudo svn import -m "initial import" cashier.cpp file:usr/local/svn/repos > Password: > svn: E150002: Path 'file:///usr/local/svn/repos' already exists > > How should i be going about this? > > sent from Mountain Lion >
Re: Local Repo
Hi David, I just noticed that you have four slashes on the beginning of your URL. Only three are needed for file-local URLs. FYI, file-local URLs look like this: file://localhost/path/to/file Since "localhost" is assumed if missing, you can shorten it to this: file:///path/to/file If you put "//" a the beginning of the file-path, you are specifying an absolute path rather than a relative path. But, since file URLs generally start from the root directory anyway you end up with the same object. file://localhost//path/to/file degenerates to file:///path/to/file -Joseph On Sep 25, 2014, at 8:47 AM, jbl...@icloud.com wrote: > First, I wouldn't run svn as root like you are with 'sudo'. Instead, change > the ownership of your repo so that you have write access. > > > Your command was trying to import 'cashier.cpp' into the repository as the > name 'repos'. You need to do this instead: > > svn import -m "initial import" cashier.cpp > file:usr/local/svn/repos/cashier.cpp > > > Import is usually used to bring a whole tree of files into a repository in > one shot. Import does not create a working copy, so you will need to > subsequently check out to begin using svn to track changes to your file. > > > > > On Sep 25, 2014, at 8:41 AM, David Lowe wrote: > >> Greetings >> >> I'm trying to set up a local repository for my schoolwork. The book >> doesn't seem to have many examples with this type of setup, so i seem to be >> stumbling a bit. First off, this part seemed to go okeh: >> >> $ sudo svnadmin create /usr/local/svn/repos >> >> But then this bit doesn't: >> >> $ sudo svn import -m "initial import" cashier.cpp >> file:usr/local/svn/repos >> Password: >> svn: E150002: Path 'file:///usr/local/svn/repos' already exists >> >> How should i be going about this? >> >> sent from Mountain Lion >> >
Re: Data Commit Limit in SVN V1.8.9 !!! [Urgent]
Hi, > On 25 Sep 2014, at 15:47, Mohsin Abbas wrote: > > please help me in this regard i am waiting for your respose. You had responses, with links to patches and a workaround of alternative transport mentioned. Andreas
Re: Starting to use vendor branch with existing code
If I'm not mistaken, this sounds like a perfect use for the least-used form of the merge command. Specifically, create the vendor folder (for simplicity, call this location "A") Move your existing version of the vendored item (call this location B) to a new location (location C). Copy the vendor item to location B (svn copy A B) Check out working copy of B. Three way merge changes between A & C onto the working copy of B. (svn merge A C .) Resolve conflicts & commit. Delete location C. Now you have a folder at location B which is derived from your vendor folder at A. Eric On Mon, Sep 22, 2014 at 8:18 AM, Phillip Seaver wrote: > We are using vendor branches for most third-party libraries, but there are > a few projects in our source tree that haven't been brought in via vendor > branches. Some of them have local modifications, too. > > Is there a recommended way to start using vendor branches with them? For > one unmodified project, I deleted the directory and copied it over from the > vendor branch, but that caused a (hopefully) one-time problem with tree > conflicts. We had to update to the revision with the delete then update to > head in order to avoid the conflict. > > Thanks, > > Phillip >
SVN Commit Failed For Data larger Than 2 GB [How To Resolve]
Good Day Team, I am using Subversion 1.8.9 server on linux OS and tortoise SVN client at windows. When I try to commit data larger then 2+ GB my commit failed. I tried to google on different websites they provided below solution : 1 : Set LimitRequestBody to 0 in the server side httpd.conf file. But Apache Web server ( Apache 2.2 ) allows 2 GB only max limit for data in HTTP request. Now tell me how can I commit files which having size more than 2 GB ? How can I increase data limit in apache webserver more than 2 GB ? OR I assume we can not commit data more than 2 GB because svn not allows us for this ? Please shed some light on this issue this is urgent. Regards Mohsin Abbas
Re: SVN Commit Failed For Data larger Than 2 GB [How To Resolve]
On Thu, Sep 25, 2014 at 6:34 PM, Mohsin Abbas wrote: > Good Day Team, > > I am using Subversion 1.8.9 server on linux OS and tortoise SVN client > at windows. When I try to commit data larger then 2+ GB my commit > failed. I tried to google on different websites they provided below > solution : > > 1 : Set LimitRequestBody to 0 in the server side httpd.conf file. > > But Apache Web server ( Apache 2.2 ) allows 2 GB only max limit for > data in HTTP request. Now tell me how can I commit files which having > size more than 2 GB ? How can I increase data limit in apache > webserver more than 2 GB ? OR I assume we can not commit data more > than 2 GB because svn not allows us for this ? > Please shed some light on this issue this is urgent. For pete's sake, it's like asking how to put a pool ball in your mouth. Just Don't Do That... If you have to use files that large, switch to svn+ssh:// or svn://.
Re: Local Repo
On 2014 Sep 25, at 8:47 AM, jbl...@icloud.com wrote: > Your command was trying to import 'cashier.cpp' into the repository as the > name 'repos'. Thank you for your thorough explanation. sent from Mountain Lion
Subversion encountered a serious problem
--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\libsvn_wc\wc_db.c' line 8731: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK ---
