RE: SVN "Relay"
As far as I can tell, from the "vulnerability": <<< GENERATES A FULL SSL CERTIFICATE WHICH THE VICTIM'S BROWSER WILL PROMPT HIM TO ACCEPT: webmitm -dd >>> The user needs to accept the man-in-the-middle certificate. -- -Justin -Original Message- From: Istace Emmanuel [mailto:istace.emman...@hotmail.com] Sent: Monday, August 02, 2010 12:01 PM To: 'Les Mikesell' Cc: users@subversion.apache.org Subject: RE: SVN "Relay" " Can you point me to something specific?" No problem, here a video (the "fun" side) : http://www.youtube.com/watch?v=Aak6-B3JORE An article : http://forums.remote-exploit.org/tutorials-guides/19852-ssl-spoof-using-wire shark-decode-ssl-packets.html "If you are concerned about your service provider maybe you should use someone else - or a service that lets you run your own system images where you could set up a blowfish-based vpn." I haven't choose that :( But as i say, it's a temporary solution -Message d'origine- De : Les Mikesell [mailto:lesmikes...@gmail.com] Envoyé : lundi 2 août 2010 17:07 À : users@subversion.apache.org Objet : Re: SVN "Relay" On 8/2/2010 8:56 AM, Istace Emmanuel wrote: > " Should I be worried about banking transactions or credit card orders?" > Yeah :( > > " You could use any kind of VPN you want with the remote site. Use an > IPSEC tunnel between hosts if you don't trust SSL. Or OpenVPN with blowfish." > No, because the SVN is on a SaaS cloud, so we just have access to the > service and not the system. So we can't install a VPN server and > remember, vpn and ipsec use SSL. Search on google about SSL Spoofing > ;) Can you point me to something specific? I see things about spoofing some other site's certificate and some things about specific implementations being subject to man-in-the-middle attacks but nothing that looks like a generic weakness. If you are concerned about your service provider (who would have the best opportunity to arrange a man-in-the-middle connection), maybe you should use someone else - or a service that lets you run your own system images where you could set up a blowfish-based vpn. -- Les Mikesell lesmikes...@gmail.com
RE: SVN "Relay"
" Can you point me to something specific?" No problem, here a video (the "fun" side) : http://www.youtube.com/watch?v=Aak6-B3JORE An article : http://forums.remote-exploit.org/tutorials-guides/19852-ssl-spoof-using-wire shark-decode-ssl-packets.html "If you are concerned about your service provider maybe you should use someone else - or a service that lets you run your own system images where you could set up a blowfish-based vpn." I haven't choose that :( But as i say, it's a temporary solution -Message d'origine- De : Les Mikesell [mailto:lesmikes...@gmail.com] Envoyé : lundi 2 août 2010 17:07 À : users@subversion.apache.org Objet : Re: SVN "Relay" On 8/2/2010 8:56 AM, Istace Emmanuel wrote: > " Should I be worried about banking transactions or credit card orders?" > Yeah :( > > " You could use any kind of VPN you want with the remote site. Use an > IPSEC tunnel between hosts if you don't trust SSL. Or OpenVPN with blowfish." > No, because the SVN is on a SaaS cloud, so we just have access to the > service and not the system. So we can't install a VPN server and > remember, vpn and ipsec use SSL. Search on google about SSL Spoofing > ;) Can you point me to something specific? I see things about spoofing some other site's certificate and some things about specific implementations being subject to man-in-the-middle attacks but nothing that looks like a generic weakness. If you are concerned about your service provider (who would have the best opportunity to arrange a man-in-the-middle connection), maybe you should use someone else - or a service that lets you run your own system images where you could set up a blowfish-based vpn. -- Les Mikesell lesmikes...@gmail.com
Re: SVN "Relay"
On 8/2/2010 8:56 AM, Istace Emmanuel wrote: " Should I be worried about banking transactions or credit card orders?" Yeah :( " You could use any kind of VPN you want with the remote site. Use an IPSEC tunnel between hosts if you don't trust SSL. Or OpenVPN with blowfish." No, because the SVN is on a SaaS cloud, so we just have access to the service and not the system. So we can't install a VPN server and remember, vpn and ipsec use SSL. Search on google about SSL Spoofing ;) Can you point me to something specific? I see things about spoofing some other site's certificate and some things about specific implementations being subject to man-in-the-middle attacks but nothing that looks like a generic weakness. If you are concerned about your service provider (who would have the best opportunity to arrange a man-in-the-middle connection), maybe you should use someone else - or a service that lets you run your own system images where you could set up a blowfish-based vpn. -- Les Mikesell lesmikes...@gmail.com
Re: SVN "Relay"
On Mon, Aug 02, 2010 at 01:40:38PM +0100, Giulio Troccoli wrote: > > > And if you decide to use svnsync for mirroring, note that the > > way the book describes the mirroring setup is vulnerable to a > > race condition. > > Make sure to read this issue: > > http://subversion.tigris.org/issues/show_bug.cgi?id=3546 > > To avoid the problem described in issue #3546, you should > > make the mirror repository pull changes from the master via a > > cronjob, and synchronise svnsync jobs using a file lock on > > the computer hosting the mirror repository. > > Only one svnsync job must be writing to the mirror repository > > at a time, or you risk breaking sync jobs. So do not push > > revisions from the master to the mirror via the post-commit > > hook (which is what the book suggests). > > Something like the following should work from a crontab on > > Linux systems: > > 0 * * * * flock -w 60 /tmp/svnsync.lock svnsync sync > > file:///path/to/repository/mirror > > > > We're working on fixing this problem such that the way the > > book describes it will work without a race condition, but > > that work is not yet complete. > > A bit OT, I just want to check that this (the race condition) does not > apply to two svnsync processes trying to sync two different > repositories. Unless both svnsync processes are writing to the same repository, the race condition cannot trigger. > I use svnsync to keep our DR server up-to-date. We have very few > people committing to the various repositories so it's more likely (and > still it's not that likely) that two people commit to two different > repositories than to the same one, so I just wanted to check thise > scenario with you. It has nothing much to do with when commits happen. The problem is that two svnsync processes running simultaneously (for whatever reason) can corrupt svnsync meta-data, causing subsequent syncs to fail because the actual latest revision in the repository doesn't match what svnsync expects. See here for a more detailed description of the problem: http://www.mail-archive.com/d...@subversion.apache.org/msg00265.html Stefan
RE: SVN "Relay"
" Should I be worried about banking transactions or credit card orders?" Yeah :( " You could use any kind of VPN you want with the remote site. Use an IPSEC tunnel between hosts if you don't trust SSL. Or OpenVPN with blowfish." No, because the SVN is on a SaaS cloud, so we just have access to the service and not the system. So we can't install a VPN server and remember, vpn and ipsec use SSL. Search on google about SSL Spoofing ;) To Tennebø Frode : Ok, i read this tonight, thank's for your help to all, i think i have what i want and all the docs.
Re: SVN "Relay"
Istace Emmanuel wrote: Ok, but that's not what i we at work. The local svn will be a "working copy" of the external svn. In fact, no user have to use the external svn if there's a local svn. The goal of this is the limit the access to the WAN. If the external svn is sync twice per day, we can limit these access and decrease the commit time for internal user (we have no external user). If you have no external users, why not put the main repository on the LAN instead of a copy? If you need an offsite copy for backup, do the svnsync periodically to the WAN copy where you don't have to worry about any other commits. A LAN commit is faster than a WAN commit (the bandwith is lower for wan) And we can have a better security, we have no control on what's do on the WAN with our data and many commit from LAN to WAN are "point of access to private data" (SSL or not, ssl is not a good security, you can spoof him easily). Should I be worried about banking transactions or credit card orders? We can limit this risk by limitting the data who are sent. You could use any kind of VPN you want with the remote site. Use an IPSEC tunnel between hosts if you don't trust SSL. Or OpenVPN with blowfish. -- Les Mikesell lesmikes...@gmail.com
RE: SVN "Relay"
> And if you decide to use svnsync for mirroring, note that the > way the book describes the mirroring setup is vulnerable to a > race condition. > Make sure to read this issue: > http://subversion.tigris.org/issues/show_bug.cgi?id=3546 > To avoid the problem described in issue #3546, you should > make the mirror repository pull changes from the master via a > cronjob, and synchronise svnsync jobs using a file lock on > the computer hosting the mirror repository. > Only one svnsync job must be writing to the mirror repository > at a time, or you risk breaking sync jobs. So do not push > revisions from the master to the mirror via the post-commit > hook (which is what the book suggests). > Something like the following should work from a crontab on > Linux systems: > 0 * * * * flock -w 60 /tmp/svnsync.lock svnsync sync > file:///path/to/repository/mirror > > We're working on fixing this problem such that the way the > book describes it will work without a race condition, but > that work is not yet complete. A bit OT, I just want to check that this (the race condition) does not apply to two svnsync processes trying to sync two different repositories. I use svnsync to keep our DR server up-to-date. We have very few people committing to the various repositories so it's more likely (and still it's not that likely) that two people commit to two different repositories than to the same one, so I just wanted to check thise scenario with you. Giulio Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Re: SVN "Relay"
On Mon, Aug 02, 2010 at 07:50:49AM -0400, Nico Kadel-Garcia wrote: > On Mon, Aug 2, 2010 at 7:41 AM, Tennebø Frode > wrote: > >> Ok, but that's not what i we at work. The local svn will be a > >> "working copy" > >> of the external svn. In fact, no user have to use the > >> external svn if there's a local svn. The goal of this is the > >> limit the access to the WAN. > > > > In that case the WAN repository can be looked on as a mirror/off-line > > backup of the LAN repository. > > > > You could use rsync to keep an up-to-date mirror on the WAN while the LAN > > is the active server. You need to set up an svn installation on the LAN, > > rsync (or some other form of copy) the initial repository from the WAN > > server to the LAN server. All uses now use the LAN repository. Some > > cron-job automatically rsyncs the LAN repository back to the WAN server. > > Only if the rsync is done as part of a post-commit operation: > otherwise, what are "atomic" operations for the Subversion repository > may be duplicated when only partially complete, and chaos may ensue. No. That's bad advice. Running rsync from the post-commit hook won't magically make the copy operation atomic. rsync will never be able to create a consistent snapshot of a live Subversion repository. Use rsync only on repositories that are known to be consistent and that no commits or revprop edits are being made to. Use 'svnadmin hotcopy' to create a copy of a repository that is consistent from Subversion's point of view. There is no other repository copying tool that can guarantee a consistent repository snapshot. Then mirror the hotcopy with any tool of your liking. Another way of doing it is dump/load. That will also be atomic, but won't copy hooks and configs, only stuff beneath the db/ directory. Making a hotcopy is much faster than creating a dump of the entire repository. Additionally, creating incremental dumps of revisions from within the post-commit hook is a good way of getting a backup of each revision in virtually real time. In case of desaster, you can use these partial dumps to fill up your backup repository to the last committed revision (or at least very close to there). Note that a fresh full dump/hotcopy is required every now and then if you allow people to change revprops (e.g. svn:log). You can also load the incremental dumps of each revisions on your repository mirror. This achieves the same effect as svnsync. Istace, just to make sure you've understood this: You need to have one repository which people commit to. You can create a mirror repository, but the mirror should only be used for read-only operations. You cannot write to the mirror and expect the changes reach the master repository. Subversion doesn't work that way. See also this section of the book: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy And if you decide to use svnsync for mirroring, note that the way the book describes the mirroring setup is vulnerable to a race condition. Make sure to read this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3546 To avoid the problem described in issue #3546, you should make the mirror repository pull changes from the master via a cronjob, and synchronise svnsync jobs using a file lock on the computer hosting the mirror repository. Only one svnsync job must be writing to the mirror repository at a time, or you risk breaking sync jobs. So do not push revisions from the master to the mirror via the post-commit hook (which is what the book suggests). Something like the following should work from a crontab on Linux systems: 0 * * * * flock -w 60 /tmp/svnsync.lock svnsync sync file:///path/to/repository/mirror We're working on fixing this problem such that the way the book describes it will work without a race condition, but that work is not yet complete. Stefan
Re: SVN "Relay"
On Mon, Aug 2, 2010 at 7:41 AM, Tennebø Frode wrote: >> Ok, but that's not what i we at work. The local svn will be a >> "working copy" >> of the external svn. In fact, no user have to use the >> external svn if there's a local svn. The goal of this is the >> limit the access to the WAN. > > In that case the WAN repository can be looked on as a mirror/off-line backup > of the LAN repository. > > You could use rsync to keep an up-to-date mirror on the WAN while the LAN is > the active server. You need to set up an svn installation on the LAN, rsync > (or some other form of copy) the initial repository from the WAN server to > the LAN server. All uses now use the LAN repository. Some cron-job > automatically rsyncs the LAN repository back to the WAN server. Only if the rsync is done as part of a post-commit operation: otherwise, what are "atomic" operations for the Subversion repository may be duplicated when only partially complete, and chaos may ensue.
RE: SVN "Relay"
> Ok, but that's not what i we at work. The local svn will be a > "working copy" > of the external svn. In fact, no user have to use the > external svn if there's a local svn. The goal of this is the > limit the access to the WAN. In that case the WAN repository can be looked on as a mirror/off-line backup of the LAN repository. You could use rsync to keep an up-to-date mirror on the WAN while the LAN is the active server. You need to set up an svn installation on the LAN, rsync (or some other form of copy) the initial repository from the WAN server to the LAN server. All uses now use the LAN repository. Some cron-job automatically rsyncs the LAN repository back to the WAN server. Make sure that only this mechanism can touch the WAN repository or you are FUBARed. -Frode -- ^ Frode Tennebø | email: frode.tenn...@saabgroup.com ^ | Saab Technologies Norway AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |
Re: SVN "Relay"
On Aug 2, 2010, at 05:16, Istace Emmanuel wrote: > Ok, but that's not what i we at work. The local svn will be a "working copy" > of the external svn. In fact, no user have to use the external svn if > there's a local svn. The goal of this is the limit the access to the WAN. If > the external svn is sync twice per day, we can limit these access and > decrease the commit time for internal user (we have no external user). A LAN > commit is faster than a WAN commit (the bandwith is lower for wan) And we > can have a better security, we have no control on what's do on the WAN with > our data and many commit from LAN to WAN are "point of access to private > data" (SSL or not, ssl is not a good security, you can spoof him easily). We > can limit this risk by limitting the data who are sent. Ok, then I don't think svnsync will help. That's not how it works (and I don't know of anything that does work that way for Subversion, but I haven't done an exhaustive search).
RE: SVN "Relay"
Ok, but that's not what i we at work. The local svn will be a "working copy" of the external svn. In fact, no user have to use the external svn if there's a local svn. The goal of this is the limit the access to the WAN. If the external svn is sync twice per day, we can limit these access and decrease the commit time for internal user (we have no external user). A LAN commit is faster than a WAN commit (the bandwith is lower for wan) And we can have a better security, we have no control on what's do on the WAN with our data and many commit from LAN to WAN are "point of access to private data" (SSL or not, ssl is not a good security, you can spoof him easily). We can limit this risk by limitting the data who are sent. -Message d'origine- De : Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Envoyé : lundi 2 août 2010 12:04 À : Istace Emmanuel Cc : 'Tony Sweeney'; users@subversion.apache.org Objet : Re: SVN "Relay" On Aug 2, 2010, at 04:54, Istace Emmanuel wrote: > Ryan Schmidt wrote: >> Yes, "svnsync" is the software you are looking for. You can read all >> about it in the book: >> >> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.ht >> ml#svn.reposadmin.maint.replication >> >> You will probably want to sync constantly, not just twice a day. > > Tony Sweeney wrote: >> Actually, I think he's looking at something more along the lines of >> Perforce's P4Proxy server, but for Subversion. >> >> http://www.perforce.com/perforce/doc.current/manuals/p4sag/09_p4p.htm >> l >> >> Svnsync doesn't help in the event that someone not on his LAN >> independently commits to the Subversion server on the WAN, as you'd >> need to be able to sync bidirectionally, and I'm not even sure that's possible. > > To Ryan : Thanks a lot for this, you will make my router happy :D For > the replication i will see what's the traffic generated by a constant > réplication. This WAN svn service is a temp service, in the next week > we will host everything locally and just keep an external svn backup server. > > To Tony : It's a possibility but i don't have to do a bidirectionnal sync. > But i will have a look at your solution and choose between the two after. There shouldn't be much difference in bandwidth whether you svnsync twice a day or immediately after every revision is committed; svnsync replays the commits in order so they're going to be the same size either way. No users will be writing to the LAN mirror; all users will be writing to the master repository on the WAN, even those users who checked out from the LAN mirror. This is accomplished by setting up a write-through proxy.
Re: SVN "Relay"
On Aug 2, 2010, at 04:54, Istace Emmanuel wrote: > Ryan Schmidt wrote: >> Yes, "svnsync" is the software you are looking for. You can read all >> about it in the book: >> >> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.ht >> ml#svn.reposadmin.maint.replication >> >> You will probably want to sync constantly, not just twice a day. > > Tony Sweeney wrote: >> Actually, I think he's looking at something more along the lines of >> Perforce's P4Proxy server, but for Subversion. >> >> http://www.perforce.com/perforce/doc.current/manuals/p4sag/09_p4p.html >> >> Svnsync doesn't help in the event that someone not on his LAN independently >> commits to the Subversion server on the WAN, as you'd need to be able to >> sync bidirectionally, and I'm not even sure that's possible. > > To Ryan : Thanks a lot for this, you will make my router happy :D For the > replication i will see what's the traffic generated by a constant > réplication. This WAN svn service is a temp service, in the next week we > will host everything locally and just keep an external svn backup server. > > To Tony : It's a possibility but i don't have to do a bidirectionnal sync. > But i will have a look at your solution and choose between the two after. There shouldn't be much difference in bandwidth whether you svnsync twice a day or immediately after every revision is committed; svnsync replays the commits in order so they're going to be the same size either way. No users will be writing to the LAN mirror; all users will be writing to the master repository on the WAN, even those users who checked out from the LAN mirror. This is accomplished by setting up a write-through proxy.
RE: SVN "Relay"
Sorry for the double topic, i'm not a usual user of the mailing list... -Message d'origine- De : Istace Emmanuel [mailto:istace.emman...@hotmail.com] Envoyé : lundi 2 août 2010 11:53 À : 'Tony Sweeney' Objet : RE: SVN "Relay" To Ryan : Thanks a lot for this, you will make my router happy :D For the replication i will see what's the traffic generated by a constant réplication. This WAN svn service is a temp service, in the next week we will host everything locally and just keep an external svn backup server. To Tony : It's a possibility but i don't have to do a bidirectionnal sync. But i will have a look at your solution and choose between the two after. -Message d'origine- De : Tony Sweeney [mailto:tswee...@omnifone.com] Envoyé : lundi 2 août 2010 11:49 À : Ryan Schmidt; Istace Emmanuel Cc : users@subversion.apache.org Objet : RE: SVN "Relay" Actually, I think he's looking at something more along the lines of Perforce's P4Proxy server, but for Subversion. http://www.perforce.com/perforce/doc.current/manuals/p4sag/09_p4p.html Svnsync doesn't help in the event that someone not on his LAN independently commits to the Subversion server on the WAN, as you'd need to be able to sync bidirectionally, and I'm not even sure that's possible. Tony. > -Original Message- > From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > Sent: 02 August 2010 10:42 > To: Istace Emmanuel > Cc: users@subversion.apache.org > Subject: Re: SVN "Relay" > > > On Aug 2, 2010, at 04:38, Istace Emmanuel wrote: > > > Hi, first of all, sorry for my bad english, i'm belgium and > i'll try to do my best. > > I have a little problem. I've got a SVN server hosted in > WAN. In LAN i've got many user who use this service, but, it's really > < chatty >. I want to make a SVN Relay into the LAN. This svn server > will sync to the WAN server twice per day and my user will connect to > the LAN server and not the WAN server. How can i do that ? Is a sync > between two svn server possible ? > > Yes, "svnsync" is the software you are looking for. You can read all > about it in the book: > > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.ht > ml#svn.reposadmin.maint.replication > > You will probably want to sync constantly, not just twice a day. > > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit > http://www.messagelabs.com/email > __ >
RE: SVN "Relay"
Actually, I think he's looking at something more along the lines of Perforce's P4Proxy server, but for Subversion. http://www.perforce.com/perforce/doc.current/manuals/p4sag/09_p4p.html Svnsync doesn't help in the event that someone not on his LAN independently commits to the Subversion server on the WAN, as you'd need to be able to sync bidirectionally, and I'm not even sure that's possible. Tony. > -Original Message- > From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > Sent: 02 August 2010 10:42 > To: Istace Emmanuel > Cc: users@subversion.apache.org > Subject: Re: SVN "Relay" > > > On Aug 2, 2010, at 04:38, Istace Emmanuel wrote: > > > Hi, first of all, sorry for my bad english, i'm belgium and > i'll try to do my best. > > I have a little problem. I've got a SVN server hosted in > WAN. In LAN i've got many user who use this service, but, > it's really < chatty >. I want to make a SVN Relay into the > LAN. This svn server will sync to the WAN server twice per > day and my user will connect to the LAN server and not the > WAN server. How can i do that ? Is a sync between two svn > server possible ? > > Yes, "svnsync" is the software you are looking for. You can > read all about it in the book: > > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.ht > ml#svn.reposadmin.maint.replication > > You will probably want to sync constantly, not just twice a day. > > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit > http://www.messagelabs.com/email > __ >
Re: SVN "Relay"
On Aug 2, 2010, at 04:38, Istace Emmanuel wrote: > Hi, first of all, sorry for my bad english, i’m belgium and i’ll try to do my > best. > I have a little problem. I’ve got a SVN server hosted in WAN. In LAN i’ve got > many user who use this service, but, it’s really « chatty ». I want to make a > SVN Relay into the LAN. This svn server will sync to the WAN server twice per > day and my user will connect to the LAN server and not the WAN server. How > can i do that ? Is a sync between two svn server possible ? Yes, "svnsync" is the software you are looking for. You can read all about it in the book: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication You will probably want to sync constantly, not just twice a day.
