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.

The authors of The Expanse published an article last year acknowledging and paying tribute to the mission ("How a NASA robot messed up our science fiction"): https://www.nationalgeographic.com/science/2019/02/dear-dawn...

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.

Another thing that isn't perfect but could help is doing a search of package contents of a large distro, e.g. here's a search of Debian for packages that provide a file called "node": https://packages.debian.org/search?searchon=contents&keyword...

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.

From the Spectre paper:

> As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2).

https://spectreattack.com/spectre.pdf

There are some amusing notes about the /bin/true copyright claim here: http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html

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.

Chris Lamb, the current Debian Project Leader, has said that it will not be in stretch but could potentially be available in stretch-backports:

> If someone puts in the work, sure :) There isn't a "they" in Debian... it's, well, volunteers doing the actual grunt work if they feel it's needed..

Source: https://www.reddit.com/r/debian/comments/5a0gcf/will_python_...

With that said, I've personally packaged a simple backport of Python 3.6 (currently 3.6.2) for Debian stretch. There are pre-built Debian packages available in the releases tab, and a one-liner in the README for how to build them yourself: https://github.com/chriskuehl/python3.6-debian-stretch

You can install these alongside the regular python3.5 installation (it doesn't replace it).

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.

I found interesting djb's blog post about a theoretical scenario where mixing entropy can actually be dangerous: https://blog.cr.yp.to/20140205-entropy.html

ISPs usually use the designated block (100.64.0.0/10) for this to avoid collisions with home networks: https://tools.ietf.org/html/rfc6598#section-7

Webpass is an example of a "good" ISP that does this. It's my only qualm with them. Besides that they are outstanding. IPv6 works great.

Most operating systems have started detecting captive portals and presenting a notification. All of the modern consumer ones (OS X, Windows, Android, iOS) appear to have this detection. (I don't use it so not sure how well it works, though.)

BART doesn't have that type of ticket. You tag your Clipper card (or insert your BART ticket, if you're not a frequent rider) upon entering a station, and again when exiting at your destination.

For what it's worth, ISPs are definitely shaping traffic to try to game results on public speed tests.

I had an issue with Comcast last year where I would have large latency spikes for ~2 hours every night, and speedtest.net always remained at normal latency: https://i.fluffy.cc/kNCxLMbkF2wx7NHFJxbzcgX35Bsb5nvl.png

I couldn't find any non-speedtest sites where my latency was less than 100ms, but Comcast's own speed test, several other public speed tests, speedtest.net, and even ookla.com (the company behind speedtest.net) were perfect (the ~20ms you see on the graph).

Just keep in mind that unstable is not guaranteed to get security fixes promptly, either. The Debian Security Team only handles supported releases.

The Security Team FAQ is a good read: https://www.debian.org/security/faq#unstable

It's quite explicit in saying that if security is important to you, then you should run a supported release.

Just want to emphasize (and this is not directed specifically at you): you almost certainly shouldn't run Debian testing on anything that is public-facing. Packages get migrated to testing after some days in unstable if no high-priority bugs are filed against them during the days after their upload.

If a security patch is uploaded to unstable today, you won't get it in testing for a few days, and possibly many more if the migration gets blocked.

https://www.debian.org/devel/testing

Just be very careful which direction you point those arrows :-)

I've have similar nightmares about typoing `if` and `of` when using dd.

Good question! The problem is trying to signal it from outside the Docker container.

If your container has a process tree like

    PID 1: /bin/sh
    +--- PID 2: <your Python server>

then if you use `docker signal` from the host, it will only send a signal to PID 1, which is the shell. However the shell won't forward it on to your Python server, so nothing happens (in most cases).

dumb-init basically replaces the shell in that diagram, but forwards signals when it receives them. So when you use `docker signal`, the Python process receives the signal.

Alternatively, just eliminating the shell (so your Python app is PID 1) works for some cases, but you get special kernel behavior applied to PID 1 which you usually don't want. This is the main purpose of dumb-init.

Yup, tini is really really similar and looks pretty cool! They're solving much of the same problem. It's unfortunate that we didn't find tini before we went and wrote dumb-init.

There are some minor differences (dumb-init looks like it's probably a bit better for interactive commands since it e.g. handles SIGTSTP). You can also get process group behavior at run-time with dumb-init rather than compile time, and it's on by default unlike tini (as far as I can tell from a brief reading). But for most cases it won't make a difference.

> From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case?

The biggest issue we see at Yelp is leaking containers in test (e.g. Jenkins aborting a job but leaving the containers it spawned still running).

Depending on how you orchestrate containers, you might not encounter the issue in prod. If you're using something like Kubernates or Marathon or Paasta, they're probably going to do the "right thing" and ensure the containers are actually stopped.

We also use containers a lot in development. For example, we might put a single tool into a container, and then when developers call that tool, they're actually spawning a container without realizing it. For this use case, it's really important that signals are handled properly so that Ctrl-C (and similar) continues working.

You can simply use `git add -p` to stage hunks individually (or `git reset -p` to unstage some hunks).

As an interesting example, Lavabit tried handing over their RSA private keys in an illegible printed font:

https://nakedsecurity.sophos.com/2013/10/04/cheeky-lavabit-d...

The past few Nexus phones (and some tablets?) have had this built-in. It's amazingly convenient.

Is there a security benefit to encrypting at the filesystem layer as opposed to just encrypting the underlying block device (like dm-crypt)? It seems like whole-disk encryption would be much harder to accidentally implement insecurely.

I think for most moderately-technically-inclined people, a decent password manager is going to be much more secure (and in many cases, more convenient).

If you steal my credit card, I'll just call my bank and cancel it (and I'm not liable for any charges you made, anyway). But if you break into my email (or even something like my Facebook, which might have weaker security), it might be really hard to recover from that.

Rather than copy their suggestions for SSL configuration, I think you can probably find better (and more well-maintained) advice on the Mozilla wiki:

https://wiki.mozilla.org/Security/Server_Side_TLS

With that said, the English is actually quite good compared to most of the spam I see (although some of the synonyms don't make sense, so were probably automatically generated).