Perguntas[gpg](unix)

Sobre o GPG é mencionado o gpg-agente li a seguinte resposta:

• gpg não pede senha

Onde são mencionadas as opções --default-cache-ttle --max-cache-ttl. Então, encontrei esta fonte oficial:

• homem - GPG-AGENT(1)

--default-cache-ttl n
Set the time a cache entry is valid to n seconds. The default is 600 seconds.
Each time a cache entry is accessed, the entry's timer is reset.
To set an entry's maximum lifetime, use max-cache-ttl
 Note that a cached passphrase may not be evicted immediately from memory if
no client requests a cache operation. This is due to an internal housekeeping
function which is only run every few seconds.

--max-cache-ttl n
Set the maximum time a cache entry is valid to n seconds.
After this time a cache entry will be expired even if it
has been accessed recently or has been set using gpg-preset-passphrase.
The default is 2 hours (7200 seconds).

Portanto, considere a questão principal da seguinte forma:

• Qual é a diferença e a relação entre as opções --default-cache-ttle ?--max-cache-ttl

E como perguntas secundárias as seguintes:

• O que é exatamente o cache entry?
• Quais são os critérios para gpg-agentsaber quando considerar/aplicar as opções --default-cache-ttle ?--max-cache-ttl

Portanto, quero entender claramente os pontos/cenários/critérios sobre quando e por que foram considerados os 600 segundos (10 minutos) e 7200 segundos (2 horas) de acordo com cada opção.

Suponha que eu queira publicar (ou enviar para alguém) um arquivo. Eu também quero que os destinatários dele possam verificar se quaisquer atualizações futuras dele vêm da mesma fonte/autor do original.

A solução óbvia é enviar o arquivo original com uma chave pública e uma assinatura GPG do arquivo. Quaisquer atualizações subsequentes também serão assinadas.

Entretanto, os verificadores teriam que importar a chave pública para seu chaveiro local.

Não há uma abordagem mais flexível e menos intrusiva? Talvez não GPG, mas outra coisa?

Por exemplo, algo assim seria o ideal:

toolname --verify --pub path/to/public.key --sig path/to/signature path/to/file-to-verify

Parece que o GPG pode fazer isso, mas apenas em 3 etapas peculiares:

gpg --no-default-keyring --keyring ./temp-keyring.gpg --import pub.key
gpg --no-default-keyring --keyring ./temp-keyring.gpg --verify signature.gpg path/to/file
rm ./temp-keyring.gpg

Perguntas relacionadas: um , dois .

Gerei uma nova chave GPG para uso pessoal usando o gpg --full-generate-keycomando no FreeBSD. O nome do sistema operacional onde a chave foi criada está armazenado na própria chave? Posso usar esta chave em uma máquina Debian como se ela tivesse sido criada no Debian?

O programa pass é um utilitário de linha de comando para armazenar senhas e dados extras de formato livre em pequenos arquivos criptografados com gpg. Ele fornece um subcomando grep em particular para encontrar senhas por meio de dados extras.

Mas esse subcomando grep é dolorosamente lento na minha máquina. Tenho quase 200 senhas armazenadas e internamente cada arquivo é descriptografado gpgassim (sem a timefrente, é claro):

% time gpg -d --quiet --yes --compress-algo=none --no-encrypt-to stackoverflow.gpg
  the password output
user=0,000 sys=0,006 wall=0,382 (1,61)

O tempo de parede é de quase 0,4 segundos, o que equivale a cerca de 1 minuto para percorrer todos os arquivos.

O gpg-agentestá rodando e eu tenho esta versão:

gpg (GnuPG) 2.2.27

Duas suspeitas de por que isso é lento:

1. A inicialização gpge a comunicação gpg-agentsão lentas, apoiadas pelo fato de que os tempos de usuário + sistema são pequenos em comparação.
2. gpg-agenté lento, apoiado pelo fato de que após uma pass grepexecução seu tempo cumulativo de CPU aumenta em 60 segundos, correspondendo perfeitamente ao tempo total da execução completa.

Juntos, ambos apontam para gpg-agent, embora eu não tenha ideia de por que o agente deveria ser tão lento. Com pseu vejo isso funcionando como

/bin/gpg-agent --sh --daemon

Alguém pode esclarecer se ~ 0,3 segundos de CPU é razoável para o agente por arquivo ou se há uma maneira de melhorar isso?

EDITAR: Outras descobertas

Anexando straceao agente, encontro isto:

20200 14:57:03.701648 getrusage(RUSAGE_SELF, {ru_utime={tv_sec=133, tv_usec=890780}, ru_stime={tv_sec=0, tv_usec=99975}, ...}) = 0
20200 14:57:03.701666 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=133, tv_nsec=990762100}) = 0
20200 14:57:04.063523 getpid()          = 18035

onde temos 360ms entre clock_gettimea getpidchamada.

E com ltrace:

20472 15:04:55.035574 strlen("my-password-here")                                                      = 10
20472 15:04:55.035641 gcry_kdf_derive(0x7d884b82c008, 10, 19, 2)                                = 0
20472 15:04:55.394727 gcry_cipher_setkey(0x7d884b82cbc0, 0x7d884b82c030, 16, 0x7d884b83c000)    = 0

Então gcry_kdf_deriveleva 360ms. Faça o que fizer, posso armazenar em cache o resultado por alguns segundos com alguma configuração. (... vai buscar o código fonte).

Preciso alterar a chave gpg originalmente usada para passar meu sistema para uma chave recém-gerada.

No entanto, quando sigo o conselho que encontrei neste tópico: https://unix.stackexchange.com/questions/226944/pass-and-gpg-no-public-key, as coisas não parecem funcionar como deveriam. O comando usado e sua saída ao tentar substituir a chave gpg original por uma chave gpg alternativa foi:

$ pass init -p .password-store GPG-id
mkdir: created directory '/home/naphelge/.password-store/.password-store'
Password store initialized for GPG-id (.password-store)
[master 8d65cea] Set GPG id to GPG-id (.password-store).
 1 file changed, 1 insertion(+), 1 deletion(-)

Portanto, o comando parece estar apenas criando um novo diretório, .password-store no diretório original .password-store e criando um novo arquivo .gpg-id com o ID GPG da minha nova chave nele, e não procedendo à criptografação novamente todos os arquivos gpg em .password-store com a nova chave gpg.

O mesmo conselho é fornecido neste tópico em relação a um objetivo semelhante:https://askubuntu.com/questions/929307/how-to-change-the-gpg-key-of-the-pass-password-store

Percebi que no arquivo .gpg-id original no diretório ~/.password-store é a impressão digital da chave gpg original (sem espaços entre os (10) blocos de 4 dígitos) que é salva. Então tentei o mesmo comando acima, pass init -p .password-store FINGERPRINT-idusando a impressão digital da nova chave (sem espaços), além de tentar apenas especificar o endereço de e-mail associado à chave, para tentar iniciar a recriptografia dos arquivos gpg em .password- store com a nova chave gpg, mas sempre com o mesmo resultado.pass init -p .password-store [email protected]

Portanto, não tenho certeza, olhando outras postagens e a página de manual do pass, o que mais tentar fazer para que isso funcione. Qualquer sugestão ou conselho será apreciado. Obrigado.

Quando eu crio um par de chaves com gpg, ele armazena a chave secreta dentro de

~/.gnupg/private-keys-v1.d

Ele armazena a chave pública dentro de um arquivo de chaveiro - posso nomeá-lo ou ele usa o local padrão.

Se eu der uma olhada ( --list-public-keys e --list-secret-keys ) em minhas chaves públicas e secretas, posso ver qual par corresponde. A string/hash de 40 caracteres na saída é a mesma para ambos.

O arquivo da chave secreta é diferente desta string. Também tem 40 caracteres, mas é diferente.

Como descubro qual arquivo de chave secreta corresponde à minha chave pública?

Usando gpg 2.2.40 no Debian 12.

Estou executando o Ubuntu (via Regolith) e minha chave gpg é desbloqueada quando eu faço login. Estou executando várias operações de descriptografia em paralelo e notei que, se eu ultrapassar 7, gpg-agentvou "esquecer" que a chave já está desbloqueada e sou solicitado a fazer uma pinentry.

❯ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.10.1

Fiz um exemplo mínimo de trabalho para demonstrar isso em python.

Crie um arquivo de teste para descriptografar com: echo "something" | gpg --encrypt -o test.gpg. A execução gpg --decrypt test.gpgno shell não solicita a senha.

Usando o script abaixo, se WORKERNUMestiver definido abaixo de 8 (na minha máquina, mas defini-lo como 1, acho que deve funcionar para qualquer máquina), o script será descriptografado com satisfação, sem solicitar uma senha longa. Mas se eu aumentar para 8 ou mais, começo a receber solicitações para inserir minha senha, embora pareça que não é de todos os processos, apenas de alguns deles. A execução dos processos também obviamente começa a travar (presumo que eles estejam aguardando gpg-agent).

import subprocess
import multiprocessing as mp
import time



the_queue = mp.Queue()
WORKERNUM = 7

def worker_main(queue):
    while True:
        msg = queue.get(True)
        print(time.time(), msg)
        out = subprocess.run(["gpg", "--decrypt", "test.gpg"], capture_output=True)
        print(msg, time.time(), out.stdout)


the_pool = mp.Pool(WORKERNUM, worker_main, (the_queue,))

counter = 0
while True:
    counter += 1
    the_queue.put(counter)
    print(the_queue.qsize())
    while the_queue.qsize() > 10:
        time.sleep(0.1)

Tentei passar --batchpara o comando decrypt, mas isso não mudou nada. Estive pesquisando as páginas de manual para gpgver gpg-agentse há algo mencionado que possa estar relacionado a isso, mas não consegui encontrar nada. Eu tenho duas perguntas:

a) por que isso acontece eb) há algo que eu possa configurar para que, em vez de ter que descobrir o tamanho máximo do pool de processamento para evitar isso, gpglide com isso e não receba uma pinentry

Eu tenho uma licença com a qual estou assinando:

gpg --default-sig-expire "2024-02-14" --sign licence

Isto resulta em:

$ gpg --verify licence.gpg
gpg: Signature made Tue 13 Feb 2024 08:18:39 AM CET
gpg:                using RSA key 1234567890ABCDEF1234567890ABCDEF
gpg:                issuer "[email protected]"
gpg: Good signature from "Stewart <[email protected]>" [ultimate]
gpg: Signature expires Wed 14 Feb 2024 12:00:00 PM CET

Esse 12:00:00 PM CETé o meu problema. Geralmente vou almoçar nesse horário. Prefiro não receber ligações sobre sistemas off-line enquanto estou almoçando. É possível especificar o horário? Prefiro que expire em 13:00:00 PM CET.

--ask-sig-expiresolicita apenas o número de dias/semanas/anos:

$ gpg --ask-sig-expire --sign licence
Please specify how long the signature should be valid.
         0 = signature does not expire
      <n>  = signature expires in n days
      <n>w = signature expires in n weeks
      <n>m = signature expires in n months
      <n>y = signature expires in n years
Signature is valid for? (0) 

ISO 8601 não parece compatível:

$ gpg --default-sig-expore "2024-02-14T13:00:00+02:00" --sign licence
gpg: '2024-02-14T13:00:00+02:00' is not a valid signature expiration

A man systemd.timeespecificação não parece suportada

$ gpg --default-sig-expire "2024-02-14 13:00:00" --sign licence
gpg: '2024-02-14 13:00:00' is not a valid signature expiration

A página de manual também não sugere que um momento seja possível:

--default-sig-expire
       The default expiration time to use for signature expiration. Valid values 
       are "0" for no expiration, a number followed by the letter d (for days), 
       w (for weeks), m (for months), or  y (for years) (for example "2m" for two 
       months, or "5y" for five years), or an absolute date in the form 
       YYYY-MM-DD. Defaults to "0".

A única solução que encontrei foi alterar o fuso horário do meu sistema para o próximo fuso horário a oeste de mim, assinar e definir o fuso horário do meu sistema de volta ao meu horário original.

$ sudo mv /etc/localtime{,.backup} 
$ sudo ln -s /usr/share/zoneinfo/Europe/London /etc/localtime
$ gpg --default-sig-expire "2024-02-14" --sign licence
$ sudo mv /etc/localtime{.backup,}
$ gpg --verify licence.gpg
gpg: Signature made Tue 13 Feb 2024 08:18:39 AM CET
gpg:                using RSA key 1234567890ABCDEF1234567890ABCDEF
gpg:                issuer "[email protected]"
gpg: Good signature from "Stewart <[email protected]>" [ultimate]
gpg: Signature expires Wed 14 Feb 2024 01:00:05 PM CET

Comando de descriptografia GPG

Estou tentando descriptografar um arquivo gpge para isso estou executando (com sucesso) o seguinte comando:

gpg --passphrase "12345678" --batch --yes --no-symkey-cache filename.tar.gz.gpg

O resultado da execução do comando é:

• o arquivo filename.tar.gz.gpgé descriptografado corretamente e é criado o arquivo filename.tar.gz;
• pelas opções --passphrase "12345678" --batch --yes a GUI para inserção da senha não está aberta.

--quietAviso e opção GPG

Mas há um problema: a gpgexecução do comando anterior produz o seguinte aviso:

gpg: WARNING: no command supplied.  Trying to guess what you mean ...

e a saída correta:

gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase

Por este post , sei que pela opção --quieto comando anterior gpgnão produz nenhuma mensagem de saída.

O aviso parece dizer que no meu comando não está presente a solicitação para descriptografar o arquivo filename.tar.gz.gpg.

Minha pergunta

Então, minha pergunta é:
existe uma maneira de saber gpgse é necessário descriptografar um arquivo para evitar o aviso no command supplied.?

A caixa de diálogo de prompt da senha do GnuGPG expira após 60 segundos.

Como faço para aumentar o período de tempo limite?

(Só para esclarecer que não estou procurando default-cache-ttlapenas o tempo limite da própria caixa de diálogo da senha. Estou usando o GnuPG v2.2.23 no Fedora 33).