Consider suppressing gpg permission dialog or increasing timeout

[eloquence]

The workstation currently triggers a gpg key access permission dialog with a short timeout when decrypting data. Frequent dialogs like this are likely to cause alert fatigue -- users just click "Yes" without scrutinizing the context. In the event of malicious code execution, it's doubtful that the user would know not to grant permission that one time.

We should consider increasing the timeout so that the dialog appears only once per boot, or suppressing it altogether, unless there are security benefits that are not clear. Note that this dialog provides no protection against workstation compromise, as it requires no further authorization.

[zenmonkeykstop]

This definitely needs doing - if the recommended workflow is to log out and/or shut down the workstation between sessions, I would agree with making it as long as possible. But it should definitely be as longer than 5 mins. An hour strikes me as a good minimum value.

[ninavizz]

@zenmonkeykstop Could we increase it from 1 hour to 8 or 12 hours? Only asking, because biggy files can take +1 hours to download, and updates may take a similar amount of time to process. Curious how this may impact the threat-model or if it would violate it. Thoughts/compromises @emkll or @redshiftzero?

[conorsch]

Big fan of removing the prompt entirely, but not sure we have the ability to do so easily, given the splitgpg tooling. The splitgpg docs provide recommendations on lengthening the window:

[user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.bash_profile

Let's add the equivalent file management targeting sd-gpg to the Salt config; I believe @zenmonkeykstop is already working on this.

[redshiftzero]

i definitely think we can make it 8 hours (same time as the API token timeout)

[ninavizz]

/cc #207 re: the above notes to increase time to 8hrs @zenmonkeykstop! Noted to 'cc PRs in updates to Issues, in the future! :)

[conorsch]

Resolved via #207.