firewalls blocking CVS

firewalls blocking CVS

[Richard Stallman]

Savannah CVS on port 443 was moved to download.savannah.gnu.org,
but this wasn't documented.  It is now documented in
http://savannah.gnu.org/maintenance/CvsFromBehindFirewall.

If this doesn't work for you, please write to savannah-hackers@gnu.org.
If they can't or don't help you, please write to me personally.

Re: firewalls blocking CVS

[dhruva]

Hi,
 I went through the complete document and suggested methods (tor did
not work either). For port 443 approach, the catch is here.

-- Part of the document from the link you had sent ----
Note: we implemented that method, without warranty, for project member
SSH access only - not anonymous access. Anonymous access is available
via pserver which ought to be available to you, just like HTTP.
-- Part of the document from the link you had sent ----

The have enabled 443 as an alternative to 22. Port 22 is used only by
project members with commit access. It does not really help people
like me (involved in the emacs project but not part of the core).

On 7/6/07, Richard Stallman <rms@gnu.org> wrote:
> Savannah CVS on port 443 was moved to download.savannah.gnu.org,
> but this wasn't documented.  It is now documented in
> http://savannah.gnu.org/maintenance/CvsFromBehindFirewall.
>
> If this doesn't work for you, please write to savannah-hackers@gnu.org.
> If they can't or don't help you, please write to me personally.

Thank you for taking this up seriously. Since it is a policy issue, I
decided to mail it to this list too.

-dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: [Savannah-help-public] Re: firewalls blocking CVS

[Sylvain Beucler]

On Tue, Jul 10, 2007 at 11:33:44AM +0530, dhruva wrote:
> Hi,
> I went through the complete document and suggested methods (tor did
> not work either). For port 443 approach, the catch is here.
> 
> -- Part of the document from the link you had sent ----
> Note: we implemented that method, without warranty, for project member
> SSH access only - not anonymous access. Anonymous access is available
> via pserver which ought to be available to you, just like HTTP.
> -- Part of the document from the link you had sent ----
> 
> The have enabled 443 as an alternative to 22. Port 22 is used only by
> project members with commit access. It does not really help people
> like me (involved in the emacs project but not part of the core).
> 
> On 7/6/07, Richard Stallman <rms@gnu.org> wrote:
> >Savannah CVS on port 443 was moved to download.savannah.gnu.org,
> >but this wasn't documented.  It is now documented in
> >http://savannah.gnu.org/maintenance/CvsFromBehindFirewall.
> >
> >If this doesn't work for you, please write to savannah-hackers@gnu.org.
> >If they can't or don't help you, please write to me personally.
> 
> Thank you for taking this up seriously. Since it is a policy issue, I
> decided to mail it to this list too.
> 
> -dhruva

Hi Dhruva,


Exactly, why is your access to port 2401 blocked?


We'll need all information leading to such restrictions before to make
a decision.

If your admin also blocked Tor nodes, which is usually the simplest
way to bypass outgoing traffic restrictions, I think (s)he is serious
about not allowing you to use our CVS service, and will probably use
any mean to continue blocking you (IP-based restrictions, checking
that traffic is TLS/SSL traffic and not pserver traffic, rejecting
outgoing traffic on port 443, delegating https encryption to the proxy
etc.), unless (s)he can be convinced that CVS access is an acceptable
use of the network.


RMS wrote:
> Maybe we need to make pserver available on port 443 on some IP.
> Savannah people, is that feasible?

Providing each and every Savannah service on port 443 on a different
IP adress doesn't scale, because:
- we offer many services,
- we don't have that many IP adresses,
- port 443 is usually already taken by https; there can be only one
  https website per IP, which makes that port even more precious,
- additional IP adresses cost money.

One may point that not all services would require such a trick;
services like GNU Arch or Git provide read-only access or fall-back
read-only access via HTTP, so maybe we can make exceptions for
CVS. But write access always require port 22, and yet another IP if we
want access to port 443. So any new service will usually require 1 IP
address for normal access, and 1 or 2 additional IP adresses for
"firewall bypassing" access.

Note that ultimately, nothing forbids you from using a dedicated
virtual server (9USD/mo) or any external machine you control (eg your
computer at home), and perform the redirection from port 443 to
Savannah yourself. Check the documentation again, a spam bot recently
reverted the documentation on that topic, and I also completed it
today. This means you are not dependent on us for bypassing the proxy.



So, once we know why your outgoing traffic to CVS is blocked, we'll
either order a new IP on which we can bind cvs-pserver on port 443, or
find a better way for you to access CVS.

Again, if everything passes through port 443, network admins will
implement other ways to restrict outgoing traffic, if that's what they
want, so in the long run this doesn't sound like a good solution.

We're also open to alternatives :)

-- 
Sylvain

Re: [Savannah-help-public] Re: firewalls blocking CVS

[dhruva]

Hello,
 Thank you very much for a detailed explaination of the comlexities
involved in providng such a service.
 I have no direct way to find out the reason due to which CVS port
(2401) is blocked. The earlier companies I worked for blocked that as
part of blocking a whole lot of ports. I could not find any particular
reason. The answer I usually got was, "if you do not need it, we do
not provide it". I had to respect their decision as Emacs was not a
requirement for my official work. In another firm, I was able to
convince them to an extent. They allowed me (just me) access to a
computer which was directly connected to the internet bypassing the
local firewall, that does not happen too often. In my current work
place, we use CVS internally. Maybe, that is the reason for preventing
the that port for external access. From what little I know, a version
control system is another form of easy means to deposit data
(versioned). May be, there exists a paranoid feaar that someone may
start depositing versioned copies of compay source code! Not sure
though.
 Due to all these restrictions, I ended up developing my own tool
"cvsget.pl" which got hosted on Savannah under non-gnu tools (it does
suffer in fundamental design) grown out of frustration by being
controlled by restrictive firewalls (in 2 days!). That used the
ViewCVS web front end and a command line based web (HTTP) downloader.
 The reason I bring up this topic is I find many companies/corporates
blocking CVS port. I do not want to argue either for or against it as
it is their resource and expected to be used purly for their own
benefit. Since there are a bunch of SCM that allow access (read only)
using the standard ports, it makes it a whole lot easier for us to
work on it during normal hours. Also, I use Emacs mainly at work, I
prefer to build it and use it on my work machine rather than at home
(I get very little time at home and hence even switching on the
computer at home is almost ruled out!).
 Currently, I am using the Emacs CVS mirror on mercurial (hg). That
works on port 80 (read only) and I get to follow the mainstream Emacs
development.

On 7/15/07, Sylvain Beucler <beuc@gnu.org> wrote:
>
> Note that ultimately, nothing forbids you from using a dedicated
> virtual server (9USD/mo) or any external machine you control (eg your

I live in India (so Rupees :-) I do have a broadband connection and
can access with no restrictions. But my concerns are slightly
different (asstated above).

> So, once we know why your outgoing traffic to CVS is blocked, we'll
> either order a new IP on which we can bind cvs-pserver on port 443, or

Oh, please do not think of incurring extra expenditures. I can always
use the under utilized borad band connection at home and transfer data
through a USB stick!

> We're also open to alternatives :)

Migrating to a SCM that works natively on port 80. A distributed SCM
would really be a welcome change. I can work offline. Once I want to
publish my changes, upload the changesets from my home. It eliminates
the need for continous access to a SCM server too (with my own local
repo).

Thanks once again.

with best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: [Savannah-help-public] Re: firewalls blocking CVS

[Richard Stallman]

    In my current work
    place, we use CVS internally. Maybe, that is the reason for preventing
    the that port for external access. From what little I know, a version
    control system is another form of easy means to deposit data
    (versioned). May be, there exists a paranoid feaar that someone may
    start depositing versioned copies of compay source code! Not sure
    though.

Please try asking your sysadmins and tell us what they say.
We need to know!

Re: [Savannah-help-public] Re: firewalls blocking CVS

[Stefan Monnier]

>     In my current work
>     place, we use CVS internally. Maybe, that is the reason for preventing
>     the that port for external access. From what little I know, a version
>     control system is another form of easy means to deposit data
>     (versioned). May be, there exists a paranoid feaar that someone may
>     start depositing versioned copies of compay source code! Not sure
>     though.

> Please try asking your sysadmins and tell us what they say.
> We need to know!

Most likely the firewall doesn't block 2401 specifically, instead it only
lets through a few specific ports such as 80 and 443 and blocks
everything else.


        Stefan

Re: [Savannah-help-public] Re: firewalls blocking CVS

[Richard Stallman]

    > Please try asking your sysadmins and tell us what they say.
    > We need to know!

    Most likely the firewall doesn't block 2401 specifically, instead it only
    lets through a few specific ports such as 80 and 443 and blocks
    everything else.

You may be right, but we still need to know what the sysadmins say
when they are _asked_ to allow these connections.

Dhruva, would you please ask them?

Re: [Savannah-help-public] Re: firewalls blocking CVS

[dhruva]

Hi,

On 7/18/07, Richard Stallman <rms@gnu.org> wrote:
> You may be right, but we still need to know what the sysadmins say
> when they are _asked_ to allow these connections.
>
> Dhruva, would you please ask them?

Sure, I will do that. I have started asking them and the response I
get is (in India) "Policies set by the parent company/HQ and has been
handed down to us". I have not yet got a straight to the point answer
yet! The other common answer is, "The firewall is not in our
administration, the proxy/firewall is located in a different location
(HQ)". Looks like Stefan's response seems to be the reason.
I will now have to start involving sysadmins sitting in different
geographical locations and this would take time.

best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: [Savannah-help-public] Re: firewalls blocking CVS

[Richard Stallman]

    Sure, I will do that. I have started asking them and the response I
    get is (in India) "Policies set by the parent company/HQ and has been
    handed down to us". I have not yet got a straight to the point answer
    yet! The other common answer is, "The firewall is not in our
    administration, the proxy/firewall is located in a different location
    (HQ)". Looks like Stefan's response seems to be the reason.
    I will now have to start involving sysadmins sitting in different
    geographical locations and this would take time.

It will take time, but please do it.  It is a useful thing to do.