mothershipper

As others have pointed out, there is a big difference between self-modifying in-memory and on-disk. The article seems to be talking about on-disk modification.

We have an internal CLI for our developers that auto-updates itself by replacing the binary on-disk. The auto-update bit only runs when the developer uses our CLI, and at most once every 24 hour. If an update is triggered, it prints out a message saying it was updated and asks the developer to re-run the command.

The upshot is we didn't have to write and distribute a second application to handle auto-updates as a background daemon, and we can be reasonably confident anybody using our CLI is +/- one version.

If for some reason it leaves the binary in a bad state, devs can still install over it with homebrew, or downloading from the releases page - haven't had to do that though in the 2 years we've had it.

Should also be using a KDF or PBKDF to generate the key from a password, instead of using the text of the password as the key.

So much this. At a previous company (Go/Python/Ruby), we used gRPC almost exclusively, and the experience was pretty good.

We're just now hitting a growth point where we need stronger contracts between our services and unfortunately really can't recommend gRPC as the primary language used is TypeScript.

We've spiked on our own protoc plugin (based on protoc-gen-star) and runtime lib (extending the google libs), but it's slow going and more likely to become tech debt than picking something off the shelf like open-api.

Not sure how I feel about the comparison to the shadow passwords file -- the shadow file doesn't contain the raw password, but a hashed version.

If someone steals the shadow password file, they still have quite a bit of computation to do to crack the credential.

Assuming one byte per character, you'd have to have a 17 character password before you're using multiple blocks. For any password shorter than that, this cipher is pretty much operating in ECB mode due to the re-used IV.

There seems to be a typo in the blog post -- yarn needs to be updated to 1.21.1, not 1.12.1