Por que os servidores de chaves pgp não respondem quando solicito chaves?

Por que os servidores de chaves pgp não respondem quando solicito chaves?

Eu tentei a linha de comando do Linux (bash 4.4.23 no kernel Arch Linux 4.18.16) com vários servidores principais:

$ gpg -v --keyserver subkeys.pgp.net --recv-keys F434104235DA97EB
gpg: using character set 'utf-8'
gpg: keyserver receive failed: Server indicated a failure
$ gpg -v --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys F434104235DA97EB
gpg: using character set 'utf-8'
gpg: keyserver receive failed: Server indicated a failure
$ gpg --debug-level 9 --keyserver  hkp://keyserver.ubuntu.com:80 --recv-keys F434104235DA97EB
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/user/.gnupg
gpg: DBG: chan_3 <- # Config: /home/user/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.2.11 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.2.11
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keyserver.ubuntu.com:80
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0xF434104235DA97EB
gpg: DBG: chan_3 <- ERR 167772379 Server indicated a failure <Dirmngr>
gpg: keyserver receive failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
$ 

Eu tentei a interface web dohttps://pgp.surfnet.nl/. Ele responde

Serviço não disponível

O servidor está temporariamente impossibilitado de atender sua solicitação devido a tempo de inatividade para manutenção ou problemas de capacidade. Por favor, tente novamente mais tarde.

Eu tentei a interface web dohttps://pgp.mit.edu. Ele responde:

Erro de proxy

O servidor proxy recebeu uma resposta inválida de um servidor upstream. O servidor proxy não conseguiu processar a solicitação GET /pks/lookup.

Motivo: Erro ao ler do servidor remoto

Eu tentei a interface da web emhttps://pgp.key-server.ioA resposta é:

Hint! Double-check if the keyserver is up and running at the expected address:port (127.0.0.1:11369).
cURL error 52: Empty reply from server
#0 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/RequestFsm.php(103): GuzzleHttp\Exception\RequestException::wrapException(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Ring\Exception\ConnectException))
#1 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/RequestFsm.php(132): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
#2 /var/www/pgp.key-server.io/vendor/react/promise/src/FulfilledPromise.php(25): GuzzleHttp\RequestFsm->GuzzleHttp\{closure}(Array)
#3 /var/www/pgp.key-server.io/vendor/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php(55): React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)
#4 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/Message/FutureResponse.php(43): GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)
#5 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/RequestFsm.php(134): GuzzleHttp\Message\FutureResponse::proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))
#6 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/Client.php(165): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
#7 /var/www/pgp.key-server.io/vendor/jenssegers/proxy/src/Adapter/Guzzle/GuzzleAdapter.php(54): GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request))
#8 /var/www/pgp.key-server.io/vendor/jenssegers/proxy/src/Proxy.php(80): Proxy\Adapter\Guzzle\GuzzleAdapter->send(Object(Symfony\Component\HttpFoundation\Request), 'http://127.0.0....')
#9 /var/www/pgp.key-server.io/src/ctubio/HKPProxy/Keyserver/Router.php(46): Proxy\Proxy->to('http://127.0.0....')
#10 /var/www/pgp.key-server.io/src/ctubio/HKPProxy/Keyserver/Router.php(14): ctubio\HKPProxy\Keyserver\Router::getHKPResponse('/pks/lookup?sea...')
#11 /var/www/pgp.key-server.io/src/ctubio/HKPProxy/Keyserver.php(19): ctubio\HKPProxy\Keyserver\Router::getResponse()
#12 /var/www/pgp.key-server.io/pub/php-proxy-keyserver.php(14): ctubio\HKPProxy\Keyserver::getResponse()
#13 {main}

Vários outros servidores principais dizem "Nenhum resultado encontrado" para qualquer chave solicitada.

  • O que está acontecendo? É um problema temporário? Mas por que todos os principais servidores estariam offline ao mesmo tempo?
  • Isso tem alguma coisa a ver com o acesso a todos os servidores de chaves bloqueados pela minha conexão (então por que posso acessar as interfaces da web que falharão?)?
  • Será que estou procurando strings inválidas? Eu não penso assim; Procurei vários diferentes, o do exemplo aqui (F434104235DA97EB) deve ser o queassinou issopacote no github ...
  • Será que não estou me conectando aos servidores principais corretos?

Responder1

Tentei seu comando subkeys.pgp.nete tive o mesmo problema. Pesquisei um pouco sobre esse servidor de chaves e não encontrei nada relevante, além de pessoas reclamando de sua falha. keyserver.ubuntu.comno entanto, funciona para mim.

[Editar] Conforme @blubberdiblubobservado, o pool.sks-keyservers.netservidor de chaves também desapareceu. Em vez disso, experimente um destes:

  • hkps://keys.gnupg.net
  • hkps://keyserver.ubuntu.com
  • hkps://keys.openpgp.org

A resposta antiga não é mais válida, mas pode ser relevante para referência

De acordo comesseexiste um servidor de chaves que consiste em um conjunto de outros servidores de chaves mais confiáveis. Esta está: pool.sks-keyservers.net. Há mais informações sobre seupágina da Internet.

Tentei usar pool.sks-keyservers.netcomo servidor de chaves e o comando conseguiu importar a chave sem problemas.

Então, para resumir e responder às suas perguntas:

  • Os servidores de chaves às vezes parecem não ser confiáveis. Talvez esses servidores de chaves sejam antigos e sem manutenção hoje em dia, eles podem estar temporariamente off-line ou simplesmente mortos. pool.sks-keyservers.netparece funcional e confiável no momento, mas isso pode mudar com o tempo.
  • A interface da Web para esses servidores de chaves pode renderizar uma página em seu navegador, mas a pesquisa de chave poderá falhar se o servidor de chaves subjacente onde as chaves estão armazenadas estiver inativo ou eles poderão não encontrar a chave se o servidor não estiver sincronizado com outros servidores de chaves.

informação relacionada