como evitar que o gnupg descriptografe os arquivos automaticamente?

1

Eu estou no OSX 10.13.4, estou aprendendo como usar o gnupg no terminal. Eu criptografei um arquivo com

gpg --cipher-algo AES256 -c input.txt -o output.gpg

ele me pediu uma senha, eu criei uma, o arquivo agora está criptografado. Mas então, quando eu emito o comando gpg -d output.gpg ele descriptografa sem me pedir a senha? _?

Como evito isso?

EDITAR

Seguindo this defini max-cache-ttl 0 em .gnupg/gpg-agent.conf e parece funcionar, alguém poderia confirmar que esta é realmente a coisa certa a fazer?

    
por Ziofil 05.05.2018 / 20:27

1 resposta

1

A configuração de max-cache-ttl 0 no seu arquivo .gnupg/gpg-agent.conf parece ser uma boa solução. Especialmente desde que funciona.

Há também a opção gpg-agent --no-allow-external-cache que deveria:

Tell Pinentry not to enable features which use an external cache for passphrases.

Some desktop environments prefer to unlock all credentials with one master pass‐ word and may have installed a Pinentry which employs an additional external cache to implement such a policy. By using this option the Pinentry is advised not to make use of such a cache and instead always ask the user for the requested passphrase.

Isso soa como se fosse sempre pedir a senha, mas não parece fazer isso. Ou, ele sempre pergunta sempre, quando existe um cache externo.

Ou, você pode continuar deixando as senhas de cache do agente gpg, mas sob demanda, limpe-as enviando um sinal SIGHUP (com kill , killall , pkill , etc):

This signal flushes all cached passphrases and if the program has been started with a configuration file, the configuration file is read again. Only certain options are honored: quiet, verbose, debug, debug-all, debug-level, debug-pinen‐ try, no-grab, pinentry-program, pinentry-invisible-char, default-cache-ttl, max- cache-ttl, ignore-cache-for-signing, no-allow-external-cache, allow-emacs-pinen‐ try, no-allow-mark-trusted, disable-scdaemon, and disable-check-own-socket. scdaemon-program is also supported but due to the current implementation, which calls the scdaemon only once, it is not of much use unless you manually kill the scdaemon

    
por 11.05.2018 / 08:16