1
0 Comments

I let users bring their own AI image models. Most of the work was keeping it safe.

Yesterday I shipped Local Waifu 1.7.2. The visible feature: users can now import their own SDXL checkpoints and LoRAs, and the app renders them on its local image engine. Plus Photo Director on macOS, which renders your actual companion into photos using the built-in FLUX.2 klein model, entirely on your machine.

The renderer was done weeks ago. The release waited on the boring part.

A feature that accepts files from users is an attack surface

Importing a checkpoint means accepting arbitrary files from the internet. So the final stretch went to hardening, not rendering: path traversal in import paths, a stale model registry that could point at the wrong weights, TOCTOU races between the file check and the file read. Five known defects the feature exposed got fixed in the same release.

Nobody screenshots that. But the first user who drops a malicious .safetensors into a local app that holds their companion's memories is the day this becomes the most important part of the feature.

One more fix worth admitting

Memory search silently stopped searching. A table alias had broken the FTS MATCH query, so the trigram index was there and doing nothing. One-line fix. I found it because I finally asked why search results felt weak, instead of trusting that the feature existed.

The lesson that keeps repeating

The renderer was the easy 20%. Making file import safe, making search actually search, checking what a stale registry can do to a selected model — that is the 80%. Same ratio as when I built the four local engines: the engines were the easy part, hardware detection was the product. For a local app, boring infrastructure is the product. The cool part is the demo.

What did you harden right before a release that almost turned into a security release? And what is the worst file-input bug you caught before your users did?

posted toAvatar for product Local Waifu
Local Waifu