Bug#1012120: libwww-dict-leo-org-perl: does not connect anymore

[Axel Beckert]

Control: tag -1 + pending

Hi,

just run into this, too.

gregor herrmann wrote:
> Control: tag + confirmed bookworm sid

Indeed, it still works on Debian 11 Bullseye, so it is clearly no
change on the server side. (Which is reverse-proxied at Cloudflare
and Cloudflare known to be quite easy on blocking specific user
agents. And there seem to be User-Agent header related issues, too:
https://rt.cpan.org/Public/Bug/Display.html?id=131931 — so that and
the ancient "HTTP/1.0" were my first guesses for potential causes.)

> A bit of debugging in the code shows that the "only" problem is
> 
> 216  close $conn or die "Connection failed: $!\n";
> 
> in /usr/share/perl5/WWW/Dict/Leo/Org.pm. If I change the die() to a
> warn() or comment out the line, everything works.

Interesting, thanks!

> I have no idea why "close $conn" fails, it might be related to
> changes in OpenSSL3 and/or IO::Socket::SSL ($conn = new
> IO::Socket::SSL(...)). -- $conn->close() fails as well without any
> further information.

I suspect OpenSSL3 as well because that was quite a bump in changes.
Nevertheless, IO::Socket::SSL is inbetween, so I looked at its
documentation.

From the IO::Socket::SSL POD:

  IO::Socket::SSL tries to emulate the usual socket behavior as good
  as possible, but full emulation can not be done. Specifically a read
  on the SSL socket might also result in a write on the TCP socket or
  a write on the SSL socket might result in a read on the TCP socket.
  Also "accept" and close on the SSL socket will result in writing and
  reading data to the TCP socket too.

  Especially the hidden writes might result in a connection reset if
  the underlying TCP socket is already closed by the peer. Unless
  signal PIPE is explicitly handled by the application this will
  usually result in the application crashing. It is thus recommended
  to explicitly IGNORE signal PIPE so that the errors get propagated
  as EPIPE instead of causing a crash of the application.

Tried that, but it didn't help.

I also checked what close() returns. It is actually "undef". Also
IO::Socket::SSL does not document any return value for close(). So the
return code is actually not meant to mean anything.

Additionally the POD also states on close():

  The default behavior is thus to only send a close notify but not
  wait for the close notify of the peer. If this is required
  "SSL_fast_shutdown" need to be explicitly set to false.

So it also does have nothing on which a success or failure could be
determined.

So IMHO we can and should just drop that "or die()".

Will do and also add some more debug output to be easier able to debug
such issues. Will also use that debug output to debug and possibly fix
https://rt.cpan.org/Public/Bug/Display.html?id=131931

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20220604/714fbd3c/attachment.sig>