rzimmerman

> Do not store secrets in environment variables

Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env file though?

> Only use trusted base images

This is a good sentiment, but docker hub also has plenty of images that are built directly from a github repo. You can inspect the Dockerfile and (as long as you trust Docker) trust that it was built as written. In this case I recommend pinning to a specific container SHA (image_name@sha256:...) in case the source repo gets compromised. For official images, you can pin to a tag IMO.

> Do not use ‘latest’ tag for base image

Regardless of the security concerns, pinning to latest will probably bite you when there's a major version bump (or even maybe a minor one). Imagine you built a container on ubuntu:latest when latest was 20.04 and some new employee gets hit with 22.04. That's a bad surprise.

> Avoid curl bashing

Evergreen fight here, but I agree with the author that you should at least validate checksums on external files before executing or using them.

> Do not upgrade your system packages

This is where the throne of lies about Docker idempotency crumbles. You have to apt-get update because Debian/Ubuntu repositories remove old versions when there are security fixes (not 100% sure on this, feel free to correct me). So if the ubuntu:20.04 image is released and there's a security update in openssh-client, running "apt-get install openssh-client" without "apt-get update" will fail. So we all run "apt-get update" and pretend that the containers we build are time-invariant. They're not, and in fact we occasionally get security updates snuck in there. Luckily Debian and Ubuntu do a good job not breaking things and no one complains. But if you build a container on Tuesday it's not guaranteed to be the same as on Wednesday and there's nothing you can do about that with a Debian distro. But it's actually fine in practice so we pretend not to notice. The point about not running "apt-get upgrade" is kind of moot - you're going to effectively be upgrading whatever you "apt-get install", so it's probably worth taking the same trade on the built-in packages.

Importantly, there's no security risk - just a configuration one.

> Do not use ADD if possible

Same as above - you should be checksumming external dependencies or self-hosting them.

> Do not root

> Do not sudo

I haven't thought deeply about these. I'd prefer to trust the container system isolation rather than playing with users and permissions. I don't understand this risk well enough to have a well-formed opinion.

Thanks for flagging that - I will double check on this and see if we can update it.

Rocket Lab is looking for a software engineer (preferably with some space or other relevant experience) in Long Beach if you're interested in building services to operate satellites including our lunar mission:

https://www.rocketlabusa.com/careers/positions/operations-so...

I actually think the “delegates” syntax for kwargs or something like it is worth adding to the standard library. The rest feels like it’s either covered by dataclasses or not something I personally want in python. Except pre_init and post_init instead of calling super().__init__. But that’s up there with if __name__ == “__main__” for being an annoying idiosyncrasy that’s too hard to change.

Most of these products have a salt packet (you’re right - you definitely should not use fresh water - it will very likely cause damage) but you still need to start with distilled or properly filtered water.

I think they’re referring to the risk of microorganisms in tap water which, when present in a sinus rinse/neti pot can cause illness or be fatal: https://www.cdc.gov/parasites/naegleria/sinus-rinsing.html

People should be using distilled water or at least a proper filter when doing a sinus rinse.

Rocket Lab | Long Beach, CA USA | Full-time (ONSITE) | https://www.rocketlabusa.com/

Rocket Lab is redefining how we access space. With over 50 satellites launched on our Electron rocket so far, we're looking to build a team of smart people that can operate our fleet of Photon satellites. These roles have a strong focus on automation through robust software and services.

Operations SW Engineer - https://www.rocketlabusa.com/careers/positions/operations-so...

Looking for backend/service/infra/devops experience to support spacecraft operations. Aerospace experience is great but not required for this role.

- Works with the operations team, fight software, IT, and ground support to build services that support the full cycle of satellite operations

- Help build an agile, modern software team

- Reports on metrics, SLAs, and SLOs like uptime, performance, and cloud resource utilization

- Works with the operations team to develop workflows and processes that are robust and support Rocket Lab’s growing fleet of spacecraft

Spacecraft Operations Engineer - https://www.rocketlabusa.com/careers/positions/spacecraft-op...

Looking for people with spacecraft experience (or similar relevant experience) who can help automate operations and work with internal customers to run on orbit experiments. This role has strong software and scripting components.

- Develop scripts, software, and tools to automate day-to-day operations of Rocket Lab’s Photon satellites

- Work with the launch operations team, flight software team, and other design teams to develop operational plans for Photon missions

- Work to improve the efficiency of satellite operations through automation and metrics-based decisions

There’s a lot of good examples of time schedules here but I have one thing I do every morning that helps me. I have a running notebook of things I need to do (just a daily log in OneNote). Before I start my day, I go through yesterday’s log and make sure I check off what I did. I add anything that’s obviously missing. I make a copy of this list in a note with today’s date. Then I look at my calendar and email and add anything that’s missing.

Next, I mark each item with a color for “must get done today”, “must get done this week”, and “can be later”. I create a new column and copy in the smaller list of what o want to do today. I add in personal stuff like a run, weights, meditation, laundry, etc.

As a third step I make a rough schedule for the day. It’s just text with some times and tasks. I try to make it under-aggressive. As the day goes on I adjust and check things off.

It helps keep me from feeling overwhelmed and makes sure I get the important things done first.

I do hope Python keeps incorporating more of the "good stuff" from functional programming. List/dict/set comprehensions make code better - I can look at something and see very clearly that it's correct. Type hinting is a great compromise between beginner/quick scripting needs and offering a fully-baked type system. Type hints do a lot more than most people expect - you can create useful compound and custom types (like Tuple[Int, Str, Iterable]). If we can get some pattern matching in there I'm not sure what I'd do. Spend less time debugging test failures I guess. Not sure what I'd do with that time. Maybe see my family or learn how to bake pastry. Or finally clean the top of the stove. Or just write more Python in the same amount of time? I don't know. Pattern matching.

Cool library, though.

This is effectively the same paradox some friends and I discussed in college. Another way of looking at it is:

If you connect an ideal voltage source through a resistor R to a capacitor C, the amount of energy required to charge the capacitor is CV^2 while the amount of energy that winds up in the charged capacitor is 1/2 CV^2. The other 1/2 CV^s is dissipated across R. This is unaffected by the value of R, even as R -> 0. The only thing that changes is the charge time.

R = 0 is impossible for real circuits, but no matter how close you get you still lose half of that energy in the resistor.

Under is unambiguously correct if you have a cat.

Bingo

A lot of people complain that Face ID doesn't work when they wear skiing gear or a mask. I'd argue that most humans can't identify me when I wear a mask, so it's a bit hard to expect my phone to do better.

I do prefer Face ID for almost everything except payments. Apple pay with Touch ID was a much better experience. The awkward double tap + stare at my phone for 2 seconds isn't great. Having an Apple Watch makes this much better but I do miss placing my phone near the reader and putting my finger on the sensor.

Thank you for clearly articulating why using AES-ECB here is not as bad as the penguin image everyone seems to know. It's still a bad choice - you really need to prove to yourself that your data stream isn't susceptible and it's honestly easier just to use an appropriate stream cipher mode.

I absolutely agree that the real deserved flak is for saying "end-to-end encryption" when that's clearly not what's happening. Honestly, I don't know how they could make their product work as well as it does with actual end-to-end (consumer to consumer) encryption. Self-hosted solutions can do this but their servers are doing a lot more than ferrying raw data streams around. That's why their meetings work so well with 200+ participants.

They also deserve criticism for saying AES-256 when they're using 128-bit keys, but like you said it's not a security issue. I suppose they could be referring to TLS that they use to set up connections and meetings rather than the stream itself but that's a stretch.

I agree, it's probably lack of appropriate expertise. There are much more subtle and useful ways to make this intentionally weak (like subtle nonce reuse with GCM). Or just giving Chinese authorities access to the key like the article implies.

The only thing I can think if is that maybe the protocol Zoom is using precludes prepending the nonce due to the packet format. But surely there's some way to do this with packet counters and user IDs. It's possible this was an intermediate step but I'm really stretching for excuses here.

AES-ECB isn't necessarily insecure, it's just very easy to misuse (and I agree what the article described is a misuse). I think the argument is that if there are patterns in the input data, the same patterns will show up in the AES-ECB encrypted data, just with different values. Compressed data should be high entropy and hard to predict, so there really shouldn't be structure or patterns to the input data. There's no guarantee that any given compression algorithm provides sufficient randomness, though.

It's possible some protocol issues prohibit the use of other stream cipher modes like AES-GCM. I can't think of any but maybe:

* Dropped packets/out of order packets. You should be able to include the IV/counter with the packet but maybe the protocol prohibits that.

* Avoiding reusing counters between participants - seems like you could just use the participant ID as part of the counter and avoid this

* Concerns about partial packet loss - shouldn't happen with UDP and GCM would handle this just as well

I'm trying but I can't think of a good reason to do it this way.

It's definitely a terrible choice for uncompressed images or video. I'm arguing it probably isn't that bad for highly compressed video. That being said, if you're encrypting any data stream you should use an appropriate stream cipher.

I'm actually not sure - that's a good point. The whole point of compressing audio for video conferencing is to preserve human speech, so things that produce radically different waveforms but "sound the same" to us might show up as patterns. I guess it's better to avoid the question entirely and use an appropriate stream cipher!

I agree - all security is assembled from lower level primitives and can be insecure despite using good building blocks. AES (even AES-128) is a fine choice, ECB mode is even okay in some contexts, but using that a stream cipher is not appropriate.

Using AES in ECB mode is clearly a bad choice, but honestly it's not that horrible for high entropy data like compressed audio/video. I'm sure someone could prove me wrong one day, but it seems hard to extract any useful patterns out of compressed audio/video. It does check the box of "uses encryption" for regulatory reasons (while missing the intent). It's pretty egregious considering how easy this is to get right.

The 128-bit key is not inherently wrong if they were rotating these out during the stream. That being said, there's no reason not to do it right and use a mode like GCM with a longer key - most hardware supports acceleration for AES-256 these days. It can actually be slower to use a 128-bit key on 64-bit systems.

While I respect the decision not to disclose the waiting room vulnerability, it's pretty obvious what's going on given the context. They probably shouldn't have mentioned where the vulnerability is.

I'm honestly surprised anyone with technical knowledge thought that Zoom was actually doing end-to-end encryption given how the software works. All of the video transcoding/downconversion is clearly happening on the server. Your client is not sending multiple compressed streams for varying connection bandwidths. That's the main reason a lot of people like Zoom - it actually works well with dozens or hundreds of participants.

I had a similar experience. I had a tick bite on my ear and didn't think much about it. A week or two later I noticed a secondary bullseye rash on my leg. I am also very lucky that my mother knew what it was and I was treated quickly with no complications.

They probably wouldn't - you wouldn't want the phone to die if someone unplugged the charger during high usage.

My guess would be both - it draws wall power up to a point and once it hits the limit of the charger (usually 5W for the small iPhone cubes) the rest comes out of the battery. So light use might still trickle the battery, but turning on the camera probably drains the battery slightly.

If your “throwaway” code works fine in production for years without any active maintenance and the only down side is that it needs a rewrite five years later, was it really that bad? Or is it the exact thing tech debt refers to - borrowing future time to work on what’s important? If I had to make a point it would be that there’s no line between code that needs to be replaced right now and code that is perfect and lasts for decades - it’s a spectrum and circumstances influence your tolerance.

There's a good Star Trek Voyager episode that deals with this: https://memory-alpha.fandom.com/wiki/Photons_Be_Free

In this case the holographic doctor writes a novel and there's confusion about who owns the property rights to his work. There was a fascinating panel at Comic Con a few years ago where some prominent lawyers discussed Star Trek episodes like this and specifically brought up the monkey selfie as precedent.

I don't have any answers but it's a good episode.

Edit: The episode is https://memory-alpha.fandom.com/wiki/Author,_Author_(episode...

I had a different take-away from that movie. My understanding was that Kirk avoided facing death/the no-win scenario his entire life. He cheated on the Kobayashi Maru and found clever ways around losing anything his entire life. It wasn't until the end of the movie that he finally had to face his "Kobayashi Maru" and deal with losing Spock. My lesson learned is that Kirk's assertion that "he doesn't believe in no-win scenarios" is naive and that how we deal with death and "how we deal with death is at least as important as how we deal with life, wouldn’t you say?"

To make it a fair comparison to full-time or even part-time work as an employee, I think you'd need to take into account the cost of car insurance, health insurance, having a car, car maintenance, gas, a smart phone + plan, time spent getting inspected, and other overhead. It's probably closer to ~$15/hr after all of that. I wouldn't be surprised if they derived $21 as California minimum wage + costs of driving.

Thanks for this really concise answer. Here's a paper we did a while back that lists the launch history and some of the different orbit types of the Dove satellites: https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=3...