gpg2 --fetch-keys

[Damien Goutte-Gattat]

On 05/28/2016 03:30 PM, Dashamir Hoxha wrote:
> I get this general error and I have no idea what is wrong:

I have the same error with a dirmngr freshly built from master.

Looking in dirmngr's log file, I see that the URL you provide redirects 
to another URL through a 302 HTTP reply, and the error occurs when 
following that redirection:

---8<-----
DBG: chan_0 <- KS_FETCH -- 
https://github.com/dashohoxha/egpg/raw/gnupg-2.1/tests/gnupg/DA94668A.gpg.asc
URL 
'https://github.com/dashohoxha/egpg/raw/gnupg-2.1/tests/gnupg/DA94668A.gpg.asc' 
redirected to 
'https://raw.githubusercontent.com/dashohoxha/egpg/gnupg-2.1/tests/gnupg/DA94668A.gpg.asc' 
(302)
TLS handshake failed: The TLS connection was non-properly terminated.
error connecting to 
'https://raw.githubusercontent.com/dashohoxha/egpg/gnupg-2.1/tests/gnupg/DA94668A.gpg.asc': 
Network error
--->8-----

If I tell gpg to fetch the key with the final URL, it succeeds without 
any error.

I observe a similar problem when the server replies with a 301 redirect:

---8<-----
DBG: chan_2 <- KS_FETCH -- https://incenp.org/dgouttegattat.asc
URL 'https://incenp.org/dgouttegattat.asc' redirected to 
'https://incenp.org/srv/dgouttegattat.asc' (301)
TLS handshake failed: A TLS packet with unexpected length was received.
dirmngr[24048.2] error connecting to 
'https://incenp.org/srv/dgouttegattat.asc': Network error
--->8-----

Again, there is no error if I fetch from the final URL. So it does look 
like a bug in the handling of HTTP redirections.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160528/c28c2463/attachment.sig>