Queries about SVN (Security related)
Dear Sir, We are in the process of selecting SVN system in our company, could you please clarify following points. 1. Restricting branching activity based on roles specified. That is denying branch functionality to users based on there roles. 2. Denying delete/add folder to certain users, it is not just r or r/w. if user has r/w access but shouldn't have delete or add access, only modify commit should be accessible. 3. Is it possible host repos in 2 different physical locations? 4. How to delete folders or file permanently. As of now we are using following software for svn access: Collabnet Subversion Edge 2.0.1 SVN 1.6 Tortoise 1.6. We are using SVN system as trail basis before adapting for entire company. So please clarify above issues. Thanks & Regards, Jerryleen S Project Coordinator, PRDC ** Please consider the environment before printing this email. Do it only if it is absolutely necessary. DISCLAIMER: The contents of this email including attachment(s), if any, are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you have received this mail in error, please notify the sender immediately and destroy all copies of this message and any attachment(s).Computer viruses or other malware can be transmitted by email. Therefore, please check this email and any attachment(s) for the presence of viruses, malware, etc. The PRDC accepts no liability whatsoever for any damage - whether direct or consequential - caused by any virus, malware, etc. transmitted by this email. **
RE: Queries about SVN (Security related)
> -Original Message- > From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] > Sent: 25 November 2011 06:32 > Subject: Queries about SVN (Security related) > > Dear Sir, > > We are in the process of selecting SVN system in our company, > could you please clarify following points. > > 1. Restricting branching activity based on roles specified. >That is denying branch functionality to users based on there roles. > 2. Denying delete/add folder to certain users, it is not just >r or r/w. if user has r/w access but shouldn't have delete or >add access, only modify commit should be accessible. This functionality is not "baked in". It might well be possible to do with a pre-commit hook but you (your admin team) would need to write and maintain the script. Personally I have not tried to do such things. > 3. Is it possible host repos in 2 different physical locations? What do you mean by host? There is built-in support for providing read-only mirrors (also as write-through proxies) but if you want multiple 'master' repositories then you need to look to WanDISCO's proprietry MultiSite extension. > 4. How to delete folders or file permanently. I assume you mean "remove completely from all history"? Ignoring all the arguments about if a source control product should even allow this, it is only currently possible by 'dump', 'dumpfilter' and 'reload'ing the whole repository. It is a feature on the roadmap (http://subversion.apache.org/roadmap.html) called 'obliterate' but not soon. > As of now we are using following software for svn access: > > Collabnet Subversion Edge 2.0.1 > SVN 1.6 > Tortoise 1.6. > > We are using SVN system as trail basis before adapting for > entire company. So please clarify above issues. I assume you have found and read the online subversion book? http://svnbook.red-bean.com/en/1.7/index.html > Thanks & Regards, > > Jerryleen S > > Project Coordinator, PRDC > > ** > > Please consider the environment before printing this email. > Do it only if it is absolutely necessary. > > DISCLAIMER: > The contents of this email including attachment(s), if any, > are intended for the exclusive use of the addressee(s) and > may contain proprietary, confidential or privileged > information. If you have received this mail in error, please > notify the > sender immediately and destroy all copies of this message and > any attachment(s).Computer viruses or other malware > can be transmitted by email. Therefore, please check this > email and any attachment(s) for the presence of viruses, malware, > etc. The PRDC accepts no liability whatsoever for any damage > - whether direct or consequential - caused by any virus, malware, > etc. transmitted by this email. > ** > > ...can you remove the above disclaimer from posts to public mail lists (it makes no sense)? ~ mark c
RE: Queries about SVN (Security related)
Dear Mark, Thanks for prompt reply, is it possible to give hook script for first 2 queries as I have done exhaustive search in search forums but haven't found hook script to do the following action > 1. Restricting branching activity based on roles specified. >That is denying branch functionality to users based on there roles. > 2. Denying delete/add folder to certain users, it is not just >r or r/w. if user has r/w access but shouldn't have delete or >add access, only modify commit should be accessible. 3rd query > 3. Is it possible host repos in 2 different physical locations? I meant in Collabnet admin GUI we can give location of only one data location, i.e., if we want to place repos in more than one machine or physical location, is it possible. I assume you have found and read the online subversion book? http://svnbook.red-bean.com/en/1.7/index.html Yes I have PDF copy of this file, it is very informative. I have been maintaining SVN since 2 months using this document. Thanks & Regards, Jerryleen S Project Coordinator, PRDC -Original Message- From: Cooke, Mark [mailto:mark.co...@siemens.com] Sent: Friday, November 25, 2011 12:48 PM To: Jerryleen S; users@subversion.apache.org Cc: channaveeraswamy Subject: RE: Queries about SVN (Security related) > -Original Message- > From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] > Sent: 25 November 2011 06:32 > Subject: Queries about SVN (Security related) > > Dear Sir, > > We are in the process of selecting SVN system in our company, > could you please clarify following points. > > 1. Restricting branching activity based on roles specified. >That is denying branch functionality to users based on there roles. > 2. Denying delete/add folder to certain users, it is not just >r or r/w. if user has r/w access but shouldn't have delete or >add access, only modify commit should be accessible. This functionality is not "baked in". It might well be possible to do with a pre-commit hook but you (your admin team) would need to write and maintain the script. Personally I have not tried to do such things. > 3. Is it possible host repos in 2 different physical locations? What do you mean by host? There is built-in support for providing read-only mirrors (also as write-through proxies) but if you want multiple 'master' repositories then you need to look to WanDISCO's proprietry MultiSite extension. > 4. How to delete folders or file permanently. I assume you mean "remove completely from all history"? Ignoring all the arguments about if a source control product should even allow this, it is only currently possible by 'dump', 'dumpfilter' and 'reload'ing the whole repository. It is a feature on the roadmap (http://subversion.apache.org/roadmap.html) called 'obliterate' but not soon. > As of now we are using following software for svn access: > > Collabnet Subversion Edge 2.0.1 > SVN 1.6 > Tortoise 1.6. > > We are using SVN system as trail basis before adapting for > entire company. So please clarify above issues. I assume you have found and read the online subversion book? http://svnbook.red-bean.com/en/1.7/index.html > Thanks & Regards, > > Jerryleen S > > Project Coordinator, PRDC > > ** > > Please consider the environment before printing this email. > Do it only if it is absolutely necessary. > > DISCLAIMER: > The contents of this email including attachment(s), if any, > are intended for the exclusive use of the addressee(s) and > may contain proprietary, confidential or privileged > information. If you have received this mail in error, please > notify the > sender immediately and destroy all copies of this message and > any attachment(s).Computer viruses or other malware > can be transmitted by email. Therefore, please check this > email and any attachment(s) for the presence of viruses, malware, > etc. The PRDC accepts no liability whatsoever for any damage > - whether direct or consequential - caused by any virus, malware, > etc. transmitted by this email. > ** > > ...can you remove the above disclaimer from posts to public mail lists (it makes no sense)? ~ mark c ** Please consider the environment before printing this email. Do it only if it is absolutely necessary. DISCLAIMER: The contents of this email including attachment(s),
RE: Queries about SVN (Security related)
[Please reply in-line, it makes it easier to see the full context...] > -Original Message- > From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] > Sent: 25 November 2011 09:43 > To: Cooke, Mark; users@subversion.apache.org > Cc: channaveeraswamy > Subject: RE: Queries about SVN (Security related) > > -Original Message- > From: Cooke, Mark [mailto:mark.co...@siemens.com] > Sent: Friday, November 25, 2011 12:48 PM > To: Jerryleen S; users@subversion.apache.org > Cc: channaveeraswamy > Subject: RE: Queries about SVN (Security related) > > > -Original Message- > > From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] > > Sent: 25 November 2011 06:32 > > Subject: Queries about SVN (Security related) > > > > Dear Sir, > > > > We are in the process of selecting SVN system in our company, > > could you please clarify following points. > > > > 1. Restricting branching activity based on roles specified. > >That is denying branch functionality to users based on > >their roles. > > 2. Denying delete/add folder to certain users, it is not just > >r or r/w. if user has r/w access but shouldn't have delete or > >add access, only modify commit should be accessible. > > This functionality is not "baked in". It might well be > possible to do with a pre-commit hook but you (your admin > team) would need to write and maintain the script. > Personally I have not tried to do such things. > > Dear Mark, > > Thanks for prompt reply, is it possible to give hook script > for first 2 queries as I have done exhaustive search in > search forums but haven't found hook script to do the following action Sorry, I have no experience in doing this having only done a few simple post-commit hooks on windows. I too find it difficult to find good hook examples, especially for windoze. Have you looked at the default pre-commit.tmpl that is installed in your hooks directory? That shows how to get the author name and references a perl script to do some authorisation checking... > > > 3. Is it possible host repos in 2 different physical locations? > > > > What do you mean by host? There is built-in support for > > providing read-only mirrors (also as write-through proxies) > > but if you want multiple 'master' repositories then you need > > to look to WanDISCO's proprietry MultiSite extension. > > > I meant in Collabnet admin GUI we can give location of only > one data location, i.e., if we want to place repos in more > than one machine or physical location, is it possible. > Do you mean separate repositories? That is down to how you configure apache. I have not used the Collabnet admin GUI having decided at the start that I wanted to understand what was going on. You can easily declare multiple SVNParentPath locations (I do this for hosting separate groups of projects) within the one apache config. However, AFAIK you need the data files on storage "local" to the server (networked storage does not seem to be recommended). I use a virtualised windoze server box with virtual local disk space but we have modest storage requirements so far. To use a separate server I would assume you need to setup apache & subversion on that server too... ~ mark c > > 4. How to delete folders or file permanently. > > I assume you mean "remove completely from all history"? > Ignoring all the arguments about if a source control product > should even allow this, it is only currently possible by > 'dump', 'dumpfilter' and 'reload'ing the whole repository. > It is a feature on the roadmap > (http://subversion.apache.org/roadmap.html) called > 'obliterate' but not soon. > > > As of now we are using following software for svn access: > > > > Collabnet Subversion Edge 2.0.1 > > SVN 1.6 > > Tortoise 1.6. > > > > We are using SVN system as trail basis before adapting for > > entire company. So please clarify above issues. > > I assume you have found and read the online subversion book? > > http://svnbook.red-bean.com/en/1.7/index.html > Yes I have PDF copy of this file, it is very informative. I > have been maintaining SVN since 2 months using this document. > > Thanks & Regards, > > Jerryleen S > > Project Coordinator, PRDC >
Re: Queries about SVN (Security related)
On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark wrote: > [Please reply in-line, it makes it easier to see the full context...] >> > Dear Sir, >> > >> > We are in the process of selecting SVN system in our company, >> > could you please clarify following points. >> > >> > 1. Restricting branching activity based on roles specified. >> > That is denying branch functionality to users based on >> > their roles. >> > 2. Denying delete/add folder to certain users, it is not just >> > r or r/w. if user has r/w access but shouldn't have delete or >> > add access, only modify commit should be accessible. >> >> This functionality is not "baked in". It might well be >> possible to do with a pre-commit hook but you (your admin >> team) would need to write and maintain the script. >> Personally I have not tried to do such things. Amen. Pre-commit scripting is extremely powerful and flexible, because it supports whatever a scripting language can do. But let's be clear. If they have "modify" access, they have "delete" access, at least with the scripting and authorization structures I've seen. "Create" access is a bit different: there are setups that allow creating tags, for example, but not deleting them. You also want to think very hard about what kind of access you provide, and what kind of layout you use. Apache access allows access control through normal Apache configurations, which can be quite sophisticated, but presents the old (and much lamented by me) problem that the UNIX and Linux Subversion clients store their passwords in clear text, by default, for http:// or https:// access. It's why I insiste on svn+ssh access, and that has different tools for controlling access based on the svnserve configuration. Workflow will also matter tomake it usable. Will people work in one large repository with lots of branches and distinct projects, each with their own branches and trunks and tags? This is common, and may be easier to manage, but means one authorization and access setup to manage and to screw up. If it's chaning all the time, it's easy to cut off *everyone's* access with one typo, and there aren't currently GUI's or sophisticated editing tools for managing this, so use caution before getting too cute. >> > > 3. Is it possible host repos in 2 different physical locations? >> > >> > What do you mean by host? There is built-in support for >> > providing read-only mirrors (also as write-through proxies) >> > but if you want multiple 'master' repositories then you need >> > to look to WanDISCO's proprietry MultiSite extension. >> > >> I meant in Collabnet admin GUI we can give location of only >> one data location, i.e., if we want to place repos in more >> than one machine or physical location, is it possible. >> > Do you mean separate repositories? That is down to how you configure apache. > I have not used the Collabnet admin GUI having decided at the start that I > wanted to understand what was going on. You can easily declare multiple > SVNParentPath locations (I do this for hosting separate groups of projects) > within the one apache config. However, AFAIK you need the data files on > storage "local" to the server (networked storage does not seem to be > recommended). I use a virtualised windoze server box with virtual local disk > space but we have modest storage requirements so far. There's also the more sophisticated tools of WanDisco's commercial grade "multi-home" setup, designed to keep multiple repositories synchronized and available for failover behavior. Interesting stuff that I've not had the money and personal requirement for, but it might serve for this. >> > 4. How to delete folders or file permanently. >> >> I assume you mean "remove completely from all history"? >> Ignoring all the arguments about if a source control product >> should even allow this, it is only currently possible by >> 'dump', 'dumpfilter' and 'reload'ing the whole repository. >> It is a feature on the roadmap >> (http://subversion.apache.org/roadmap.html) called >> 'obliterate' but not soon. Yes, "obliterate". Its absence is a long-standing problem: Once someone stores an inappropriate and bulky DVD image, or a file with confidential information in it, it's an extremely awkward and fragile and manual process to remove it. The easiest way is usually to transfer the data to a new repository with the old data excluded, and switch everyone to use the new repository. This can cause real problems with ongoing work, but it works. Note that the idea that a source control should *never* eliminate all traces of its history is understandable. It used to be too easy to completely screw up a CVS repository with a casual deletion of a particular file, and Subversion is sometimes referred to as "CVS done right", so the historical resistance to such a feature is understandable. It's very dangerous and could delete exactly the change history you need badly to figure out when something got screwed up and by who
RE: Queries about SVN (Security related)
Dear Niko, Cooke, Thanks for the suggestions, will try putting forward this ideas to management. Hoping for the best. Thanks and Regards, Jerryleen S Project Coordinator, PRDC -Original Message- From: Nico Kadel-Garcia [mailto:nka...@gmail.com] Sent: Friday, November 25, 2011 9:18 PM To: Cooke, Mark Cc: Jerryleen S; users@subversion.apache.org; channaveeraswamy Subject: Re: Queries about SVN (Security related) On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark wrote: > [Please reply in-line, it makes it easier to see the full context...] >> > Dear Sir, >> > >> > We are in the process of selecting SVN system in our company, >> > could you please clarify following points. >> > >> > 1. Restricting branching activity based on roles specified. >> > That is denying branch functionality to users based on >> > their roles. >> > 2. Denying delete/add folder to certain users, it is not just >> > r or r/w. if user has r/w access but shouldn't have delete or >> > add access, only modify commit should be accessible. >> >> This functionality is not "baked in". It might well be >> possible to do with a pre-commit hook but you (your admin >> team) would need to write and maintain the script. >> Personally I have not tried to do such things. Amen. Pre-commit scripting is extremely powerful and flexible, because it supports whatever a scripting language can do. But let's be clear. If they have "modify" access, they have "delete" access, at least with the scripting and authorization structures I've seen. "Create" access is a bit different: there are setups that allow creating tags, for example, but not deleting them. You also want to think very hard about what kind of access you provide, and what kind of layout you use. Apache access allows access control through normal Apache configurations, which can be quite sophisticated, but presents the old (and much lamented by me) problem that the UNIX and Linux Subversion clients store their passwords in clear text, by default, for http:// or https:// access. It's why I insiste on svn+ssh access, and that has different tools for controlling access based on the svnserve configuration. Workflow will also matter tomake it usable. Will people work in one large repository with lots of branches and distinct projects, each with their own branches and trunks and tags? This is common, and may be easier to manage, but means one authorization and access setup to manage and to screw up. If it's chaning all the time, it's easy to cut off *everyone's* access with one typo, and there aren't currently GUI's or sophisticated editing tools for managing this, so use caution before getting too cute. >> > > 3. Is it possible host repos in 2 different physical locations? >> > >> > What do you mean by host? There is built-in support for >> > providing read-only mirrors (also as write-through proxies) >> > but if you want multiple 'master' repositories then you need >> > to look to WanDISCO's proprietry MultiSite extension. >> > >> I meant in Collabnet admin GUI we can give location of only >> one data location, i.e., if we want to place repos in more >> than one machine or physical location, is it possible. >> > Do you mean separate repositories? That is down to how you configure apache. > I have not used the Collabnet admin GUI having decided at the start that I > wanted to understand what was going on. You can easily declare multiple > SVNParentPath locations (I do this for hosting separate groups of projects) > within the one apache config. However, AFAIK you need the data files on > storage "local" to the server (networked storage does not seem to be > recommended). I use a virtualised windoze server box with virtual local disk > space but we have modest storage requirements so far. There's also the more sophisticated tools of WanDisco's commercial grade "multi-home" setup, designed to keep multiple repositories synchronized and available for failover behavior. Interesting stuff that I've not had the money and personal requirement for, but it might serve for this. >> > 4. How to delete folders or file permanently. >> >> I assume you mean "remove completely from all history"? >> Ignoring all the arguments about if a source control product >> should even allow this, it is only currently possible by >> 'dump', 'dumpfilter' and 'reload'ing the whole repository. >> It is a feature on the roadmap >> (http://subversion.apache.org/roadmap.html) called >> 'obliterate' but not
RE: Queries about SVN (Security related)
I haven't read the thread but I'd like to clarify one thing: a pre- commit hook sees the transaction (ie, candidate revision) as it will exist once committed. It sees exactly what is deleted and what is modified. And it can accept or reject it on that basis. On Monday, November 28, 2011 11:47 AM, "Jerryleen S" wrote: > Dear Niko, Cooke, > > Thanks for the suggestions, will try putting forward this ideas to > management. Hoping for the best. > > Thanks and Regards, > > Jerryleen S > > Project Coordinator, PRDC > > > > -Original Message- > From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > Sent: Friday, November 25, 2011 9:18 PM > To: Cooke, Mark > Cc: Jerryleen S; users@subversion.apache.org; channaveeraswamy > Subject: Re: Queries about SVN (Security related) > > On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark wrote: > > [Please reply in-line, it makes it easier to see the full context...] > > >> > Dear Sir, > >> > > >> > We are in the process of selecting SVN system in our company, > >> > could you please clarify following points. > >> > > >> > 1. Restricting branching activity based on roles specified. > >> > That is denying branch functionality to users based on > >> > their roles. > >> > 2. Denying delete/add folder to certain users, it is not just > >> > r or r/w. if user has r/w access but shouldn't have delete or > >> > add access, only modify commit should be accessible. > >> > >> This functionality is not "baked in". It might well be > >> possible to do with a pre-commit hook but you (your admin > >> team) would need to write and maintain the script. > >> Personally I have not tried to do such things. > > Amen. Pre-commit scripting is extremely powerful and flexible, because > it supports whatever a scripting language can do. But let's be clear. > If they have "modify" access, they have "delete" access, at least with > the scripting and authorization structures I've seen. > > "Create" access is a bit different: there are setups that allow > creating tags, for example, but not deleting them. > > You also want to think very hard about what kind of access you > provide, and what kind of layout you use. Apache access allows access > control through normal Apache configurations, which can be quite > sophisticated, but presents the old (and much lamented by me) problem > that the UNIX and Linux Subversion clients store their passwords in > clear text, by default, for http:// or https:// access. It's why I > insiste on svn+ssh access, and that has different tools for > controlling access based on the svnserve configuration. > > Workflow will also matter tomake it usable. Will people work in one > large repository with lots of branches and distinct projects, each > with their own branches and trunks and tags? This is common, and may > be easier to manage, but means one authorization and access setup to > manage and to screw up. If it's chaning all the time, it's easy to cut > off *everyone's* access with one typo, and there aren't currently > GUI's or sophisticated editing tools for managing this, so use caution > before getting too cute. > > > >> > > 3. Is it possible host repos in 2 different physical locations? > >> > > >> > What do you mean by host? There is built-in support for > >> > providing read-only mirrors (also as write-through proxies) > >> > but if you want multiple 'master' repositories then you need > >> > to look to WanDISCO's proprietry MultiSite extension. > >> > > >> I meant in Collabnet admin GUI we can give location of only > >> one data location, i.e., if we want to place repos in more > >> than one machine or physical location, is it possible. > >> > > Do you mean separate repositories? That is down to how you configure > > apache. I have not used the Collabnet admin GUI having decided at the > > start that I wanted to understand what was going on. You can easily > > declare multiple SVNParentPath locations (I do this for hosting separate > > groups of projects) within the one apache config. However, AFAIK you need > > the data files on storage "local" to the server (networked storage does not > > seem to be recommended). I use a virtualised windoze server box with > > virtual local disk space but we have modest storage requirements so far. > > There's also the more sophisticated t
RE: Queries about SVN (Security related)
Does mod_dav_svn expose the FS API for "open txn and edit it"? If so, how does it ensure that the txn it modifies hasn't been passed to a pre-commit hook already? [ asking in the hope that someone knows the answer; if no one answers and I can't find it myself I'll follow up on dev@ ] On Monday, November 28, 2011 8:36 AM, "Daniel Shahaf" wrote: > I haven't read the thread but I'd like to clarify one thing: a pre- > commit hook sees the transaction (ie, candidate revision) as it will > exist once committed. It sees exactly what is deleted and what is > modified. And it can accept or reject it on that basis. > > On Monday, November 28, 2011 11:47 AM, "Jerryleen S" > wrote: > > Dear Niko, Cooke, > > > > Thanks for the suggestions, will try putting forward this ideas to > > management. Hoping for the best. > > > > Thanks and Regards, > > > > Jerryleen S > > > > Project Coordinator, PRDC > > > > > > > > -Original Message- > > From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > > Sent: Friday, November 25, 2011 9:18 PM > > To: Cooke, Mark > > Cc: Jerryleen S; users@subversion.apache.org; channaveeraswamy > > Subject: Re: Queries about SVN (Security related) > > > > On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark wrote: > > > [Please reply in-line, it makes it easier to see the full context...] > > > > >> > Dear Sir, > > >> > > > >> > We are in the process of selecting SVN system in our company, > > >> > could you please clarify following points. > > >> > > > >> > 1. Restricting branching activity based on roles specified. > > >> > That is denying branch functionality to users based on > > >> > their roles. > > >> > 2. Denying delete/add folder to certain users, it is not just > > >> > r or r/w. if user has r/w access but shouldn't have delete or > > >> > add access, only modify commit should be accessible. > > >> > > >> This functionality is not "baked in". It might well be > > >> possible to do with a pre-commit hook but you (your admin > > >> team) would need to write and maintain the script. > > >> Personally I have not tried to do such things. > > > > Amen. Pre-commit scripting is extremely powerful and flexible, because > > it supports whatever a scripting language can do. But let's be clear. > > If they have "modify" access, they have "delete" access, at least with > > the scripting and authorization structures I've seen. > > > > "Create" access is a bit different: there are setups that allow > > creating tags, for example, but not deleting them. > > > > You also want to think very hard about what kind of access you > > provide, and what kind of layout you use. Apache access allows access > > control through normal Apache configurations, which can be quite > > sophisticated, but presents the old (and much lamented by me) problem > > that the UNIX and Linux Subversion clients store their passwords in > > clear text, by default, for http:// or https:// access. It's why I > > insiste on svn+ssh access, and that has different tools for > > controlling access based on the svnserve configuration. > > > > Workflow will also matter tomake it usable. Will people work in one > > large repository with lots of branches and distinct projects, each > > with their own branches and trunks and tags? This is common, and may > > be easier to manage, but means one authorization and access setup to > > manage and to screw up. If it's chaning all the time, it's easy to cut > > off *everyone's* access with one typo, and there aren't currently > > GUI's or sophisticated editing tools for managing this, so use caution > > before getting too cute. > > > > > > >> > > 3. Is it possible host repos in 2 different physical locations? > > >> > > > >> > What do you mean by host? There is built-in support for > > >> > providing read-only mirrors (also as write-through proxies) > > >> > but if you want multiple 'master' repositories then you need > > >> > to look to WanDISCO's proprietry MultiSite extension. > > >> > > > >> I meant in Collabnet admin GUI we can give location of only > > >> one data location, i.e., if we want to place repos in more > >
RE: Queries about SVN (Security related)
Dear Daniel, It's a valid argument, we need to determine whether the commit is for deleting or adding or modifying existing file. Accordingly we need to intervene using pre-commit hook, but as per discussion in the thread it isn't possible to differentiate deleting or adding or modifying transaction during pre-commit script. If anybody has any solutions please reply asap. Thanks & Regards, Jerryleen S Project Coordinator, PRDC -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Monday, November 28, 2011 12:11 PM To: Jerryleen S; Nico Kadel-Garcia; Cooke, Mark Cc: users@subversion.apache.org; channaveeraswamy; danie...@elego.de Subject: RE: Queries about SVN (Security related) Does mod_dav_svn expose the FS API for "open txn and edit it"? If so, how does it ensure that the txn it modifies hasn't been passed to a pre-commit hook already? [ asking in the hope that someone knows the answer; if no one answers and I can't find it myself I'll follow up on dev@ ] On Monday, November 28, 2011 8:36 AM, "Daniel Shahaf" wrote: > I haven't read the thread but I'd like to clarify one thing: a pre- > commit hook sees the transaction (ie, candidate revision) as it will > exist once committed. It sees exactly what is deleted and what is > modified. And it can accept or reject it on that basis. > > On Monday, November 28, 2011 11:47 AM, "Jerryleen S" > wrote: > > Dear Niko, Cooke, > > > > Thanks for the suggestions, will try putting forward this ideas to > > management. Hoping for the best. > > > > Thanks and Regards, > > > > Jerryleen S > > > > Project Coordinator, PRDC > > > > > > > > -Original Message- > > From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > > Sent: Friday, November 25, 2011 9:18 PM > > To: Cooke, Mark > > Cc: Jerryleen S; users@subversion.apache.org; channaveeraswamy > > Subject: Re: Queries about SVN (Security related) > > > > On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark wrote: > > > [Please reply in-line, it makes it easier to see the full context...] > > > > >> > Dear Sir, > > >> > > > >> > We are in the process of selecting SVN system in our company, > > >> > could you please clarify following points. > > >> > > > >> > 1. Restricting branching activity based on roles specified. > > >> > That is denying branch functionality to users based on > > >> > their roles. > > >> > 2. Denying delete/add folder to certain users, it is not just > > >> > r or r/w. if user has r/w access but shouldn't have delete or > > >> > add access, only modify commit should be accessible. > > >> > > >> This functionality is not "baked in". It might well be > > >> possible to do with a pre-commit hook but you (your admin > > >> team) would need to write and maintain the script. > > >> Personally I have not tried to do such things. > > > > Amen. Pre-commit scripting is extremely powerful and flexible, because > > it supports whatever a scripting language can do. But let's be clear. > > If they have "modify" access, they have "delete" access, at least with > > the scripting and authorization structures I've seen. > > > > "Create" access is a bit different: there are setups that allow > > creating tags, for example, but not deleting them. > > > > You also want to think very hard about what kind of access you > > provide, and what kind of layout you use. Apache access allows access > > control through normal Apache configurations, which can be quite > > sophisticated, but presents the old (and much lamented by me) problem > > that the UNIX and Linux Subversion clients store their passwords in > > clear text, by default, for http:// or https:// access. It's why I > > insiste on svn+ssh access, and that has different tools for > > controlling access based on the svnserve configuration. > > > > Workflow will also matter tomake it usable. Will people work in one > > large repository with lots of branches and distinct projects, each > > with their own branches and trunks and tags? This is common, and may > > be easier to manage, but means one authorization and access setup to > > manage and to screw up. If it's chaning all the time, it's easy to cut > > off *everyone's* access with one typo, and there aren't currently > > GUI's or sophisticated editing tools for ma
Re: Queries about SVN (Security related)
Jerryleen S wrote on Tue, Nov 29, 2011 at 10:50:06 +0530: > but as per discussion in the thread it isn't possible to differentiate > deleting or adding or modifying transaction during pre-commit script. > I don't understand what you're claiming. The situation is: - The pre-commit hook knows the EXACT contents of the transaction (which will become a revision if the hook does exit(0)). That in particular includes the equivalent of 'svn log -qv' of the txn. (five minutes on a file:///tmp/r repository with 'svnlook -t' will confirm or refute this) - The pre-commit hook can modify the txn before it becomes a revision. Such modifications cannot be communicated to the client performing the commit. (for the former assertion, see svn_fs_open_txn() and similar FS APIs. for the latter, the client code (libsvn_ra and libsvn_wc) assumes that the changes sent to the server are those committed, and updates the wc state based on the changes sent.) > On Monday, November 28, 2011 8:36 AM, "Daniel Shahaf" > wrote: > > I haven't read the thread but I'd like to clarify one thing: a pre- > > commit hook sees the transaction (ie, candidate revision) as it will > > exist once committed. It sees exactly what is deleted and what is > > modified. And it can accept or reject it on that basis.
Re: Queries about SVN (Security related)
On Tue, Nov 29, 2011 at 7:44 AM, Daniel Shahaf wrote: > Jerryleen S wrote on Tue, Nov 29, 2011 at 10:50:06 +0530: >> but as per discussion in the thread it isn't possible to differentiate >> deleting or adding or modifying transaction during pre-commit script. >> > > I don't understand what you're claiming. The situation is: > > - The pre-commit hook knows the EXACT contents of the transaction > (which will become a revision if the hook does exit(0)). That in > particular includes the equivalent of 'svn log -qv' of the txn. > > (five minutes on a file:///tmp/r repository with 'svnlook -t' will > confirm or refute this) > > - The pre-commit hook can modify the txn before it becomes a revision. > Such modifications cannot be communicated to the client performing the > commit. > > (for the former assertion, see svn_fs_open_txn() and similar FS APIs. > for the latter, the client code (libsvn_ra and libsvn_wc) assumes that > the changes sent to the server are those committed, and updates the wc > state based on the changes sent.) To reiterate what Daniel said: you can perfectly well see the difference between an Add (A), a Delete (D) or a Modification (M) in a pre-commit hook. The command 'svnlook changed -t ' will give you a list of everything that's about to be changed by the transaction in question. Lines beginning with A indicate Additions, D for Deletes and M for Modifications. Of course this is only speaking at file/directory granularity (which files/directories are added, deleted, modified). If you want to know if a Modified file has additions, deletions or modifications, you'll have to examine/parse the output of 'svnlook diff' to see the concrete content changes ... -- Johan
RE: Queries about SVN (Security related)
Dear Johan, Now we sure that we can differentiate between different forms of commit, is it possible by any SVN enthusiasts to help me write pre-commit script to deny delete/add transactions for certain users. Thanks & Regards, Jerryleen S Project Coordinator, PRDC -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, November 29, 2011 7:16 PM To: Jerryleen S Cc: Nico Kadel-Garcia; Cooke, Mark; users@subversion.apache.org; channaveeraswamy; Daniel Shahaf Subject: Re: Queries about SVN (Security related) On Tue, Nov 29, 2011 at 7:44 AM, Daniel Shahaf wrote: > Jerryleen S wrote on Tue, Nov 29, 2011 at 10:50:06 +0530: >> but as per discussion in the thread it isn't possible to differentiate >> deleting or adding or modifying transaction during pre-commit script. >> > > I don't understand what you're claiming. The situation is: > > - The pre-commit hook knows the EXACT contents of the transaction > (which will become a revision if the hook does exit(0)). That in > particular includes the equivalent of 'svn log -qv' of the txn. > > (five minutes on a file:///tmp/r repository with 'svnlook -t' will > confirm or refute this) > > - The pre-commit hook can modify the txn before it becomes a revision. > Such modifications cannot be communicated to the client performing the > commit. > > (for the former assertion, see svn_fs_open_txn() and similar FS APIs. > for the latter, the client code (libsvn_ra and libsvn_wc) assumes that > the changes sent to the server are those committed, and updates the wc > state based on the changes sent.) To reiterate what Daniel said: you can perfectly well see the difference between an Add (A), a Delete (D) or a Modification (M) in a pre-commit hook. The command 'svnlook changed -t ' will give you a list of everything that's about to be changed by the transaction in question. Lines beginning with A indicate Additions, D for Deletes and M for Modifications. Of course this is only speaking at file/directory granularity (which files/directories are added, deleted, modified). If you want to know if a Modified file has additions, deletions or modifications, you'll have to examine/parse the output of 'svnlook diff' to see the concrete content changes ... -- Johan ** Please consider the environment before printing this email. Do it only if it is absolutely necessary. DISCLAIMER: The contents of this email including attachment(s), if any, are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you have received this mail in error, please notify the sender immediately and destroy all copies of this message and any attachment(s).Computer viruses or other malware can be transmitted by email. Therefore, please check this email and any attachment(s) for the presence of viruses, malware, etc. The PRDC accepts no liability whatsoever for any damage - whether direct or consequential - caused by any virus, malware, etc. transmitted by this email. ** ** Please consider the environment before printing this email. Do it only if it is absolutely necessary. DISCLAIMER: The contents of this email including attachment(s), if any, are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you have received this mail in error, please notify the sender immediately and destroy all copies of this message and any attachment(s).Computer viruses or other malware can be transmitted by email. Therefore, please check this email and any attachment(s) for the presence of viruses, malware, etc. The PRDC accepts no liability whatsoever for any damage - whether direct or consequential - caused by any virus, malware, etc. transmitted by this email. **
