Re: [certi-dev] how CVS obstructs my automatized tests

[Eric Noulard]

2008/11/18 Gotthard, Petr <address@hidden>:
> Eric, all,
>
> This is a "public lament" explaining why I cannot make automatized
> tests. :-(
>
> The CVS protocol uses own protocol and own protocol number, which is
> very often blocked by company firewalls. It's very hard for persons
> behind such firewalls to even obtain a latest software version from CVS.

Yes be sure I really know how painful it is to be behind a "stupid" firewall.
I even file a feature/bug report a long time ago on Savannah
(part of the request was about BehindFirewall trouble):
https://savannah.gnu.org/support/?func=detailitem&item_id=105200

See the generic FAQ entry of Savannah too:
https://savannah.gnu.org/maintenance/CvsFromBehindFirewall

> For example, I have to physically re-plug my notebook to a different
> network, what can hardly be automated.

I see, when I was "blocked" behind a firewall I did use
http://proxytunnel.sourceforge.net/
with the "at that time" supported ssh access on 443  :=)

I think it ceased working at some point
(may be it's back now  since
 https://savannah.gnu.org/maintenance/CvsFromBehindFirewall
 says you can do it on download.sv.gnu.org:443)

> The SVN (I guess you knew this will come) doesn't have this
> disadvantage, but if this would be the only reason it's not worth the
> migration effort.

SVN may be configured with a web server for responding on 443
but this is not the only solution.
You may well use CVS+SSH with an SSH running on port 443 as well.

The trouble here is that network security administrator do
not want to examine "real" threat and oftenly says that they won't
EVER open port 2401 or 22 because it's too dangerous.

Then you may discover (real case I faced) that port 23
(you know the 20 years old clear-passwd telnet protocol)
is wide open because some projects ABSOLUTELY NEEDS it :-)

We have stateful firewall that won't make any in-going
traffic pass if it does not correspond to identified outgoing request,
port 22 is just as [un]safe as 443 and may well be handled by
the average proxy, you may easilly  authorize specific traffic
to/from FQDN like cvs.sv.nongnu.org etc....
Secure solution exists, network admin sometimes do not want to ear about it.

However another point is that I didn't noticed that Savannah
did add support for SVN:
https://savannah.gnu.org/forum/forum.php?forum_id=5340
https://savannah.gnu.org/maintenance/SvN

Now:
-  It is still flagged "WIP, Work In Progress"
   https://savannah.gnu.org/maintenance/WhenSvN

- It seems to be usable either with svn (port 3690) or ssh+svn (22) protocol
  which does not solves the issue :-(

You complain is noted I'll try to see what we can do in order to improve that.
-- 
Erk