mothershipper | 4 years ago | on: On self-modifying executables in Rust
mothershipper's comments
mothershipper | 5 years ago | on: Playing with symmetric encryption algorithms in Ruby
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.
mothershipper | 5 years ago | on: gRPC on Node.js with Buf and TypeScript
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.
mothershipper | 5 years ago | on: Show HN: Ugliest.app – Ugly but good app platform
mothershipper | 6 years ago | on: Show HN: S-Cache – Secure storage for cryptographic secrets, modeled after sudo
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.
mothershipper | 6 years ago | on: TeamViewer stores user passwords in registry, encrypted with hard-coded key
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.
mothershipper | 6 years ago | on: Understand filesystem takeover vulnerabilities in NPM JavaScript package manager
mothershipper | 6 years ago | on: Understand filesystem takeover vulnerabilities in NPM JavaScript package manager
There seems to be a typo in the blog post -- yarn needs to be updated to 1.21.1, not 1.12.1
page 1
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.