I'm curious if you make your home directory immutable, where do you store your files like pdfs etc?

For point 1 I recall the creator of Age, Filippo Valsorda suggesting something similar:

>The .age-recipients files also include the public key for an offline disaster recovery key. I generated the key with age-keygen, encrypted it with age -p, printed the ciphertext as a QR code, and wrote the random passphrase in pen. This is a bit convoluted, but I don’t trust printers. All this was done in a tmpfs, so nothing reached storage. Only had to do this once, and have been using that key as the anchor for all my disaster recovery data. https://words.filippo.io/dispatches/passage/

You don't need security keys to enable ADP. You need to setup a Recovery Contact or create a Recovery Key.

Looks like FiloSottile may have switched from passage to 1Password:

https://bsky.app/profile/filippo.abyssdomain.expert/post/3l5...

Would be interesting to get more context why move from storing passwords locally to an online service.

Team sharing with a non-technical person, mostly.

I still have high-value passwords and CLI credentials in passage + age-plugin-yubikey.

I like Wipr. Simpler design IMHO.

Wipr 2 + NextDNS here.

Have you considered writing passage in Go to integrate age and age-plugin-yubikey as a single binary to make it more convenient to setup and use?

Combining Passage, pass-otp, and age into a single Go app has actually been on my personal hobby-project TODO list (but I haven't gotten around to it yet).

Integrating age plugins into this binary is not something I would do, though. Besides the fact that the plugins are separate projects with their own release schedules, they are also in different languages (plugin-yubikey is Rust, plugin-se is Swift, ...), and you would need to fork them anyway for communication. I guess you could bundle the binaries together in a package, and make sure the search path searches for the bundled binaries as a fallback.

I know there are specialized backup tools like restic or borg, but I like to keep things simple.

Is using age like this to encrypt my files before uploading them to untrusted cloud storage not ok?

tar > age > cloud

Some comments mention signing with minisign. Should I be doing that like this:

tar > age > minisign > cloud

If you make a second backup tomorrow, you'll end up with a new (huge) encrypted tar. restic handles deltas when creating a second backup, and writes new files so that tools like rsync or rclone have to do less work to upload the new data.

That said, I don't see anything strictly _wrong_ with your approach.

No deduplication is a tradeoff I'm willing to make for simplicity and less things that can go wrong :)

Use specialized backup tools! There are cryptographic constructions designed specifically for backup. You will get better backup and better encryption.

"Better backup" aside, as I understand that I'd miss out on deduplication and all the other things backup software can do like keeping track of what it has backed up etc.

"Better encryption": Can you explain why age's encryption isn't sufficient if it's recommended for encrypting files? Really want to understand how it's recommended for encrypting and sharing a file over an untrusted channel like email, but not recommended to encrypt a file and upload it to an untrusted server.

I made a tiny shell script that combines tar+age, you may find it useful for simplicity

https://github.com/arcxio/urn/blob/main/urn

It’s obviously not practical except for small data, for many obvious reasons.

You may expect tools such as restic or Borg or rclone should use Age. But they don’t, because they need their own file formats.

Restic is excellent. I can’t recommend it enough.