Comment by arminiusreturns

I recently did a deep dive on cli password management in an attempt to harden my bash scripts. (yes, I love bash, despite HN always loving to talk crap about it)

Pass is just a shell wrapper around gnupg, when you run pass some/secret/path, what actually happens is pass constructs and executes a gpg command (e.g., gpg --decrypt ~/.password-store/some/secret/path.gpg) and the output of gpg (the plaintext secret) is piped to pass's stdout.

Most people know this though. What I learned I didn't know before though was this:

Memory Zeroing: after it's used (e.g., copied to a pipe or stdout), GPG's internal memory management aims to zero out those memory regions used as soon as they are no longer needed

Memory Locking: GnuPG also uses mlock() (or equivalent OS-specific calls) to lock sensitive memory pages into RAM. This prevents the plaintext keys and decrypted data from being swapped out to disk, protecting against swap-file forensics or cold boot attacks.

I had been banging my head against bash trying to do those things manually, and ended up with the conclusion it was best to use pass/gpg with the following addendums (from my notes in my skeleton secure bash template):

1. Minimize secret lifetime: Use subshells, functions with local variables, and unset, disable bash history

2. Pipe secrets directly: Pass secrets via stdin or process substitution directly to the consuming program without intermediate variables if possible.

3. Rely on the tools: Use pass, gpg, or KMS CLIs that are themselves implemented in lower-level languages and can (and should) implement these memory protection techniques internally.

ps: keepassxc is the other favorite to use