Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Mon, Oct 14, 2019 at 2:12 AM Eric Wong <e...@80x24.org> wrote: > > We can also find creative ways to subvert corporate policies: > > For example; if their policy specifically prevents outgoing SMTP, > > "git imap-send" could be used. > > IMAP may be blocked, too?
Yes, was just pointing to "git imap-send" which already exists; but anything can go over HTTPS POST + Transfer-Encoding:chunked. > Bascially the only thing you can rely on is HTTP(S), through a proxy, > possibly with HTTPS inspection through a company-specific trusted > certificate that allows MITM. Right, I was tunneling arbitrary data over HTTP/1.1 via Transfer-Encoding:chunked on both requests/responses over a decade ago. Probably won't work with nginx because of input buffering, but public-inbox-httpd can be made to support it w/o buffering, too (it already does HTTPS + chunk parsing). I got something working on the server-side for git:// using Ruby back in 2009: https://public-inbox.org/git/20090702085440.gc11...@dcvr.yhbt.net/ Client-side needed some work, though... > > If their policy forbids using external "email" services, we'd > > name it "Kernel Hackers' Messaging System" or something of that > > sort and say we use an email bridge :> > > Anything named "Hacker" may be blocked, too ;-) Unpxref, then :> _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
