This is exactly the kind of project that's easy to take for granted until the day you need a specific BIOS and every download you find is dead or unverifiable. Checking against emulator source rather than trusting whatever's floating around is the right call, that's usually where these collections go wrong.

Bookmarked for when my Batocera box inevitably needs a re-flash. Do you have a cadence for pulling in new releases as RetroArch etc. cut new versions, or is this more of an as-needed refresh?

If you're on anything with a reasonably current systemd (248+, so basically any Debian 12/Fedora/Arch box), FIDO2 via systemd-cryptenroll is the one I'd reach for first, no extra daemons, actively maintained since it's just systemd itself.

HMAC-SHA1 (yubikey-luks project) is the most battle-tested of the three, but it's a third-party keyscript hook with spottier maintenance over the years. The SHA1 part isn't actually a security weakness here since it's HMAC challenge-response, not collision resistance, so don't let the algorithm name scare you off it.

OpenPGP-on-Nitrokey is the heaviest of the three (needs gpg/scdaemon alive in initramfs), but worth it if you're already using the OpenPGP applet for SSH auth or email signing.

I run FIDO2 with a TPM2 enrollment as fallback so a lost key doesn't lock me out entirely.

True fully-open WiFi camera hardware is basically nonexistent. Closest you'll get is OpenIPC (openipc.org), open source firmware for the SoCs a bunch of budget cameras use, but it's a compatibility gamble per exact model, not plug-and-play.

More realistic path for a Tapo-style setup: keep the camera on an isolated VLAN with zero internet route (kills the cloud phone-home even on stock firmware), point it at a self-hosted NVR like Frigate or Shinobi over local RTSP/ONVIF, and never touch the TP-Link app or cloud account. Doesn't make the firmware itself open, but it makes the actual footage 100% local, which is usually the part people actually care about.

If you specifically want reflashable open firmware, OpenIPC's supported-devices list is worth checking before buying anything new.

Pangolin's default docker-compose ships its own Traefik container, and that's almost always what's actually fighting your existing one, not a config typo on your end. Two ways out of it that I've seen work:

• Comment out the traefik service in Pangolin's compose file entirely and let your existing traefik instance handle routing via labels. Pangolin's docs have a section for using an existing reverse proxy that walks through pointing your own traefik at Gerbil's exposed port instead of the bundled one.
• Or the reverse: let Pangolin's traefik own ports 80/443 and demote your main one to a different port/internal-only role if it's not doing much else.

First option is cleaner if your main traefik is already handling other services and you don't want two separate ACME/cert setups running side by side.

Rough one if the creator's actually gone dark, that project's been load-bearing infrastructure for a long time. A few things holding the fort while the dust settles:

• The AUR package might just be pulled because the upstream download link broke, not necessarily dead-dead. Worth checking the AUR comments or grabbing an archived copy of the last known-good installer if you need to keep ripping today.
• makemkv-oss exists as a stripped decrypt-only fork on some distros, handles the AACS/BD+ decryption piece even without the GUI wrapped around it.
• For the actual muxing after decryption, ffmpeg with libbluray compiled in will read a decrypted BD structure fine, it's just not as one-click as MakeMKV was.
• The part that's genuinely hard to replace is ongoing AACS key updates for new discs, that's usually the real value MakeMKV was providing beyond the rip itself, not just the tool.

Hoping someone picks it back up.