Por que os pipes falham com o GPG?

Question

Estou procurando canalizar senhas para o gpg para criptografia simétrica, mas ele age como se eu não canalizasse nada, e ainda me pede a senha e a insira novamente.

Aqui está o que estou tentando (com 'enter' sendo a senha):

(echo 'enter'; echo 'enter') | gpg -c test.py

Por que isso não está funcionando?

Eu já sei que você pode usar --batch --yes --passphrase='enter' , mas isso mostrará a senha na tarefa no gerenciador de tarefas (e, portanto, parece menos seguro - diga-me se estou errado).

EDIT: Acabei de perceber que o eco provavelmente ainda apareceria no gerenciador de tarefas (apenas separadamente do comando gpg). Então, para contornar isso, eu poderia salvar a senha em um arquivo temporário e usar cat myPasswordFile em vez de echo myPassword . Dessa forma, eles teriam que obter a senha em tempo real a partir do arquivo temporário (enquanto existir) em vez de apenas registrar todas as tarefas que foram executadas e obter a senha como quiserem.

    

Answer 1

Você pode usar --passphrase-fd 0 para dizer ao gpg para ler a senha do stdin. Isso deve dar-se bem com os tubos. Não envie duas vezes; isso é necessário apenas para detecção de erros de digitação quando você faz isso de maneira interativa.

Normalmente o gpg lê a partir do tty para que você possa redirecionar a entrada e a saída e ainda ter a capacidade de inserir uma senha.

Em uma sessão de login normal, seu shell é conectado ao terminal por três descritores de arquivo: stdin, stdout e stderr. Canais e operadores de redirecionamento mudam para onde esses descritores de arquivo apontam.

Se você executar um comando sem nenhum operador de redirecionamento, todos os descritores de arquivos serão herdados do shell. Quando se lê de stdin, está lendo do tty.

Se você executar o mesmo comando com um operador de redirecionamento < , seu stdin será conectado ao arquivo cujo nome aparece após < . Se você colocar um comando no lado direito de um operador | , seu stdin será conectado a um descritor de arquivo de pipe (cuja extremidade oposta está conectada ao stdout do comando no lado esquerdo do | .)

Essa é a coisa que você provavelmente já sabia. O que você não sabia é que, além dos descritores de arquivos, há outra coisa que liga terminais e processos: o controlador de terminal . Seu processo de shell tem um terminal de controle e é herdado por todos os processos filhos, incluindo, neste caso, seu gpg .

Quando um programa deseja obter entrada de teclado do usuário, apesar do stdin não ser um terminal, ele pode acessar seu terminal de controle abrindo o arquivo especial /dev/tty .

Um tipo de programa que depende muito desse recurso é um pager (por exemplo, more , less ). Se você executar somecommand | less , o que less deseja fazer é ler algumas entradas do canal em stdin, exibir a primeira tela e, em seguida, ler no teclado para aguardar que você pressione uma tecla para informar o que fazer em seguida . stdin não pode ser tanto o pipe quanto o teclado, então less abre /dev/tty .

O terminal de controle de um processo é listado na coluna TTY por ps .