kikuchiyo has asked for the wisdom of the Perl Monks concerning the following question:

At $work, an application that uses SSL sockets began to crash with the following error message after a system upgrade:

Can't locate auto/Net/SSLeay/SSL_alert_d.al in @INC (@INC contains: /u
+sr/bin/../../lib /usr/bin/.. /usr/bin/../.. /usr/bin/../lib /usr/loca
+l/lib64/perl5/5.36 /usr/local/share/perl5/5.36 /usr/lib64/perl5/vendo
+r_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5
+) at /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 3685.

[download]

The offending line, which was introduced in IO::Socket::SSL 2.076, is this:

            $msg_name = eval { Net::SSLeay::SSL_alert_desc_string_long
+($msg_type) } || "Unknown alert";

[download]

But it is possible to trigger a similar error with just

perl -MNet::SSLeay -le 'print Net::SSLeay::SSL_alert_desc_string_long(
+1)'

[download]

This function seems to be a well-established exported function of OpenSSL, which is exposed to the Perl module in SSLeay.xs. The SSLeay.so library certainly has a similarly named symbol. But the error message, with the truncated function name seems to indicate that some breakage is going on around function export/import/autoloading.

My questions:

  1. This looks like a bug, but where to report to? IO::Socket::SSL, because it uses a function it's (possibly) not supposed to, or Net::SSLeay, because they have this weirdly broken function in the first place?
  2. Looking at Net::SSLeay's code as it is deployed, it has a bunch of these .al files in the auto/Net/SSLeay directory. Apparently these are created by AutoSplit which is a part of Autoload or something. But the functions in those files seem to exist in SSLeay.pm as well, so what is the point of this nonsense?

Replies are listed 'Best First'.
Re: Can't locate auto/Net/SSLeay/SSL_alert_d.al
by hippo (Archbishop) on May 12, 2023 at 13:06 UTC

    I think it's a bug in IO::Socket::SSL. The docs for Net::SSLeay say

    NOTE: Please note that SSL_alert_* function have "SSL_" part stripped from their names.

    and if I call it as such then it doesn't error out for me:

    $ perl -MNet::SSLeay -le 'print Net::SSLeay::SSL_alert_desc_string_lon
+g(1)'
Can't locate auto/Net/SSLeay/SSL_alert_d.al in @INC (@INC contains: /u
+sr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_p
+erl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) a
+t -e line 1.
$ perl -MNet::SSLeay -le 'print Net::SSLeay::alert_desc_string_long(1)
+'
unknown

    [download]

    🦛

[reply]
[d/l]
      Thanks, I'll report it as such.
[reply]
[reply]
Re: Can't locate auto/Net/SSLeay/SSL_alert_d.al
by hv (Prior) on May 12, 2023 at 13:10 UTC

    But it is possible to trigger a similar error ...

    The offending line wraps the call in eval, so this should not be causing it to crash.

    I tried installing Net::SSLeay in a local 5.36 installation, and found this:

    % $PERL -MNet::SSLeay -wle 'print Net::SSLeay::SSL_alert_desc_string_l
+ong(1)'
Can't locate auto/Net/SSLeay/SSL_alert_d.al in @INC (@INC contains: /o
+pt/v5.36.0/lib/perl5/site_perl/5.36.0/x86_64-linux /opt/v5.36.0/lib/p
+erl5/site_perl/5.36.0 /opt/v5.36.0/lib/perl5/5.36.0/x86_64-linux /opt
+/v5.36.0/lib/perl5/5.36.0) at -e line 1.

% $PERL -MNet::SSLeay -wle 'print eval { Net::SSLeay::SSL_alert_desc_s
+tring_long(1) } || "not a crash"'
not a crash

    [download]

    So it is odd that it is crashing for you: is it possible that it is getting reported due to some $SIG{__DIE__} in your code (eg to write errors to a log file), but still then getting caught by the eval so not actually dying?

    In any case, I think it should initially be reported against the IO::Socket::SSL distribution, since they are calling an undocumented function in Net::SSLeay. Maybe that function was implemented in Perl in a previous version, but has since become unreachable now that it is implemented in XS.

    I note that in other parts of IO::Socket::SSL they protect certain evals by preceding them with local $SIG{__DIE__};, and the fix here might be as simple as adding that near line 3685. However the authors will probably also want to rethink their logic here.

    For your own code, note that you can detect whether you are in eval using the variable $^S. If you have $SIG{__DIE__} handlers it is often useful to look at that when deciding what the handler should do.

    Hope this helps.

[reply]
[d/l]
[select]

      I've simplified the situation somewhat: it didn't crash per se, the error was reported by a die handler that does a somewhat orderly shutdown of the application in case of a fatal error.

      The other answer in the thread has pointed out that the fix is as simple as removing the SSL_ prefix, so I'll report that to IO::Socket::SSL.

      It's also worth noting that the error only appears if tracing is enabled, and we've had $Net::SSLeay::trace = 3 in our code. Removing this line also eliminated the errors. This might explain why this wasn't noticed by others until now: apparently it's in a rarely executed part of the code.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom