Re: Smart fetch via HTTP?

From: david@lang.hm <david@lang.hm>
Date: May 19, 2007, 04:58 UTC
Message-ID: <Pine.LNX.4.64.0705182154540.6938@asgard.lang.hm>
In-Reply-To: <20070519035856.GB3141@spearce.org>

On Fri, 18 May 2007, Shawn O. Pearce wrote:

Show 22 quoted lines

> david@lang.hm wrote:
>> when a person browsing a hostile website will allow that website to take
>> over the machine the demand is created for 'malware filters' for http, to
>> do this the firewalls need to decode the http, and in the process limit
>> you to only doing legitimate http.
>>
>> it's also the case that the companies that have firewalls paranoid enough
>> to not let you get to the git port are highly likely to be paranoid enough
>> to have a malware filtering http firewall.
>
> I'm behind such a filter, and fetch git.git via HTTP just to keep
> my work system current with Junio.  ;-)
>
> Of course we're really really really paranoid about our firewall,
> but are also so paranoid that any other web browser *except*
> Microsoft Internet Explorer is thought to be a security risk and
> is more-or-less banned from the network.
>
> The kicker is some of our developers create public websites, where
> testing your local webpage with Firefox and Safari is pretty much
> required...  but those browsers still aren't as trusted as IE and
> require special clearances.  *shakes head*

this isn't paranoia, this is just bullheadedness

Show 7 quoted lines

> We're pretty much limited to:
>
> *) Running the native Git protocol SSL, where the remote system
> is answering to port 443.  It may not need to be HTTP at all,
> but it probably has to smell enough like SSL to get it through
> the malware filter.  Oh, what's that?  The filter cannot actually
> filter the SSL data?  Funny!  ;-)

we're actually paranoid enough to have devices that do man-in-the-middle decryption for some sites, and are given copies of the encryption keys that other sites (and browsers) use so that it can decrypt the SSL and check it. I admit that this is far more paranoid then almost all sites though :-)

> *) Using a single POST upload followed by response from server,
> formatted with minimal HTTP headers.  The real problem as people
> have pointed out is not the HTTP headers, but it is the single
> exchange.

Show 6 quoted lines

> If you really want a stateful exchange you have to treat HTTP as
> though it were IP, but with reliable (and much more expensive)
> packet delivery, and make the Git daemon keep track of the protocol
> state with the client.  Yes, that means that when the client suddenly
> goes away and doesn't tell you he went away you also have to garbage
> collect your state.  No nice messages from your local kernel.  :-(

unfortunantly you are right about this.

David Lang