Problem
The decryption strategies pass the password as a command-line argument to the backing tools — e.g. qpdf ... "--password=${PASSWORD}" ... (decrypt-pdf:307, :325, :347) and mutool clean -p "$PASSWORD" .... Command-line arguments of running processes are visible to any user on the host via ps//proc, so the plaintext password is briefly exposed system-wide.
This is related to but distinct from #1: #1 addresses the password appearing in the caller's shell history, whereas this is about the password appearing in the process list of the spawned tools. A prompt alone does not fix it.
Suggested fix
- For qpdf, use file/stdin password input instead of argv:
--password-file=FILE or --password-file=- (stdin). This keeps the secret out of ps.
- For mutool (which only accepts
-p on argv), consider preferring a qpdf/ghostscript path when a secret must be hidden, or document the limitation.
- Optionally expose
--password-file / --password-stdin on decrypt-pdf itself so callers never place the secret in argv either.
Problem
The decryption strategies pass the password as a command-line argument to the backing tools — e.g.
qpdf ... "--password=${PASSWORD}" ...(decrypt-pdf:307,:325,:347) andmutool clean -p "$PASSWORD" .... Command-line arguments of running processes are visible to any user on the host viaps//proc, so the plaintext password is briefly exposed system-wide.This is related to but distinct from #1: #1 addresses the password appearing in the caller's shell history, whereas this is about the password appearing in the process list of the spawned tools. A prompt alone does not fix it.
Suggested fix
--password-file=FILEor--password-file=-(stdin). This keeps the secret out ofps.-pon argv), consider preferring a qpdf/ghostscript path when a secret must be hidden, or document the limitation.--password-file/--password-stdinondecrypt-pdfitself so callers never place the secret in argv either.