ckuehl

Purely a guess, but I've sometimes been able to work backwards from the content length (very often included in HTTP server logs) to figure out what the body had to be.

Also keep in mind that if you use IP-based whitelisting, an attacker can register their own CF/Fastly account and target your origin server with whatever CDN settings they want (assuming they can discover your origin server). With Fastly at least you can even do this from the free tier.

This is a somewhat dangerous pattern for picking temporary files (from #8):

    $ NEWFILE=/tmp/newfile_${RANDOM}
    $ touch $NEWFILE

The problem is that any user on the box can create files under /tmp. An attacker can set up a bunch of symlinks like /tmp/newfile_1, ..., /tmp/newfile_99999 pointing to a file owned by your user. When your script then writes into this temporary file, you'll write through the symlink and clobber one of your own files. Especially dangerous if root :)

This has been a historic source of software vulnerabilities (often with the PID used instead as the guessable component instead of random, though). One recommended alternative is to use the `mktemp` command instead.

I've been using my packaged version pretty extensively (mostly in virtualenvs) and haven't encountered any issues yet myself, but would definitely be interested to hear (either on GitHub or here) what issues you encountered and if they occur with my packaged version as well.

I wouldn't really expect any issues since it doesn't replace `/usr/bin/python3` (it just adds a `/usr/bin/python3.6`), but it's definitely possible I just haven't run into them.

I agree. Looks like I only noticed the apt-get install line and incorrectly assumed that's what you were referring to.

A benefit of installing using your system package manager is that you can rely on your distro to manage the security of the package. If you just `pip install` it, you need to personally watch for new security bugs and upgrade (or backport them to your current version, which is what e.g. Debian will do for you). You'd also need to do that for all of the dependencies.

Up to you if you trust your distro's security team, of course :). I trust mine.

Totally agreed they have the right to monitor your network traffic, but I still think in most cases employees should try to push back on this.

At least from my view, it's not so much that I don't want my company to know what I'm doing, as that I don't trust their software to securely MITM all of my traffic. This thread doesn't fill me with confidence about the competency of these corporate MITM proxies. And the recent Cloudflare news doesn't help either -- they're effectively the world's largest MITM proxy, and even they couldn't avoid leaking a huge amount of "secure" traffic.

There are surely sectors where it's necessary for a company to MITM all traffic, but I think most companies will do better security-wise by not messing with TLS. It's just too hard to get right.