david@xxxxxxx 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* 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! ;-) *) 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. One might think you could use HTTP pipelining to try and get a bi-directional channel with the remote system, but I'm sure proxy servers are not required to reuse the same TCP connection to the remote HTTP server when the inside client piplines a new request. So any sort of hack on pipelining won't work. 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. :-( -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
