There are several different options with different levels of security, so lets outline some of the options so you can make the best decision. To automate decryption, a passphrase has to be stored somewhere (on disk, in memory, or on another machine). It is usually worth considering:
- Who has access to the machine?
- Is it publicly accessible or host a publicly accessible service?
Option 1: Store the email passphase unencrypted in your muttrc file.
Limit the read access of muttrc to the user running the cron and encrypt the underlying file system. Since your are using Gmail, create an App Password that can be rotated/revoked if it is compromised. This is probably the easiest solve for the problem.
The downside of this solution, the
root user or anyone with
sudo privileges can access this file. You can configure
sudo to require a password to help reduce that possibility.
Option 2: Store the gpg passphrase unencrypted in a file.
For this option, you are configuring mutt to run gpg non-interactively. Read access should be restricted for your mutt passwords and gpg passphrase files. You should also encrypt the underlying filesystem to protect against physical access. This only adds obscurity to just storing a password unencrypted in the muttrc. The same downsides apply, and this solution would be considered equally secure.
For gpg to be run by a non-interactive user, you will need to run gpg commands with:
--batch to disable interactive mode
--passphrase-file to provide a password for the gpg private key
--pinentry-mode loopback to redirect pinentry queries back to the caller.
So, in the mutttrc:
source "/usr/local/bin/gpg -d --batch --passphrase-file=$HOME/.passFile.txt --pinentry-mode loopback $HOME/.mutt/passwords.gpg |"
Option 3: Use a secrets management service.
No real standard exists in this space, and there are many options in this space. A secrets management service centralizes the management of secrets providing auditing and control of access to secrets at scale. Advantages and disadvantages will change dependent on your deployment and implementation, and going any further into this space would be largely opinion based.
Additionally, here is another question that largely touches on the question domain that might be helpful.