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

[Gotthard, Petr]

Many thanks for your support,
I have scheduled both certi and tests_stuite for Nightly tests on a 64b
platform (Linux-gcc-4.3.0-x86_64). Let's see what errors we get
tomorrow. ;-)

The download.sv.gnu.org:443 works fine.
https://savannah.gnu.org/maintenance/CvsFromBehindFirewall


Petr

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Eric Noulard
Sent: Tuesday, November 18, 2008 1:06 PM
To: CERTI development discussions
Subject: Re: [certi-dev] how CVS obstructs my automatized tests

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


-- 
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel