Good that you point out shell history. You probably mean stuff like secrets being passed to age via CLI params? That's quite dangerous even if you put a space before the command which excludes it from your shell history. Any user on your system has read-access to the CLI arguments of every other process on your system. I've filed an issue upstream about this: https://github.com/FiloSottile/age/issues/37
I've mentioned swap in my comment. It's a problem indeed. On Linux you can prevent memory regions from being swapped out via mlock, but only to a certain limit if you are unprivileged (limit on my machine is 64 MB it seems). Windows seems to have a way as well. It's solvable in general and RAM is cheap. It's OSs that have to catch up. Even with the looming swap danger, your data is still more safe in RAM as it doesn't neccessarily get swapped while if it's on your hdd/ssd, it is almost certain to actually land there as well (instead of living in the RAM's cache).
> The problem with stuff like "gives users read/write access" -- is that it presumes a narrow use case. What if you're encrypting digital audio? Source code? etc.
That's a good point. Due to the point you made above (swap, shell history, etc leaking data to disk), it would be best if specialized tools handled the file, which are vetted to not leak any data onto the disk. You could think of a model where age is a library, the tools manually vetted with that in mind. Or you could think of a model where age is embedded into a runtime and the tools are sandboxed wasm modules without access to anything but RAM. Admittedly this is a huge project and one shouldn't expect age to be such a runtime.
A good stopgap would age enforcing best practices by checking whether the destination of the decrypted content is a ramdisk or not. I've filed an issue about this: https://github.com/FiloSottile/age/issues/36
