Re: send-email: Net::SSLeay failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 8, 2017 at 3:32 AM, Samuel Lijin <sxlijin@xxxxxxxxx> wrote:
> On Wed, Jun 7, 2017 at 8:26 PM, Liam Breck <liam@xxxxxxxxxxxxxxxxx> wrote:
>> On Wed, Jun 7, 2017 at 5:06 PM, Samuel Lijin <sxlijin@xxxxxxxxx> wrote:
>>> On Wed, Jun 7, 2017 at 4:43 PM, Ævar Arnfjörð Bjarmason
>>> <avarab@xxxxxxxxx> wrote:
>>>> Ah, so you installed Net::SSLeay via CPAN, and then upgraded your Arch
>>>> openssl, breaking the CPAN-built *.so object?
>>>>
>>>>> Agreed that send-email should be report errors properly. It's a rather
>>>>> essential tool.
>>>>
>>>> Indeed, do you get a meaningful error if you apply my patch?
>>>
>>> FWIW I'm on Arch as well and am getting what I assume is a related error:
>>>
>>> SSLeay.c: loadable library and perl binaries are mismatched (got
>>> handshake key 0xdb80080, needed 0xde00080)
>>>
>>> The last patch I sent out was on 5/23, and I just ran a system upgrade
>>> today (only one I've done since then), which presumably is what
>>> "broke" send-email. I used CPAN to install Net::SMTP::SSL,
>>> Mime::Base64, and Authen::SASL; I assume that Net::SSLeay is installed
>>> as a dependency of one of the three (presumably the first)?
>>>
>>> I know Net::SSLeay isn't controlled by Arch's package manager:
>>>
>>> $ perldoc -l Net::SSLeay
>>> /usr/lib/perl5/site_perl/Net/SSLeay.pod
>>> $ pacman -Qo /usr/lib/perl5/site_perl/Net/SSLeay.pod
>>> error: No package owns /usr/lib/perl5/site_perl/Net/SSLeay.pod
>>>
>>> Ævar's patch unfortunately does not fix or change anything for me.
>>
>> Right because it attempts to log a diff issue.
>>
>>> Liam: when you say "uninstall" /usr/{lib,share}/perl5/site_perl/*, do
>>> you just mean rm -rf?
>>
>> You need these new arch packages:
>> perl-mime-tools perl-net-smtp-ssl perl-authen-sasl
>>
>> To uninstall the cpan stuff I did this in case I need to put anything back
>>
>> mkdir -p siteperl_uninstall/{lib,share}
>> sudo mv /usr/share/perl5/site_perl/*  siteperl_uninstall/share/
>> sudo mv /usr/lib/perl5/site_perl/*  siteperl_uninstall/lib/
>>
>> You could comment on this issue here
>> https://bugs.archlinux.org/task/54334
>
> Changed the subject line; my issue seems to be less related to yours
> than I thought. I followed the steps you describe and I'm still
> getting the mismatch error I mentioned above.
>
> The closest I've gotten to figuring this out is that for some reason
> SSLeay.so is unhappy:
>
> $ ldd -r /usr/lib/perl5/vendor_perl/auto/Net/SSLeay/SSLeay.so
>                                 linux-vdso.so.1 (0x00007ffc67fb0000)
>         libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f891e58b000)
>         libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f891e110000)
>         libc.so.6 => /usr/lib64/libc.so.6 (0x00007f891dd6b000)
>         libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f891db4d000)
>         libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f891d949000)
>         /usr/lib64/ld-linux-x86-64.so.2 (0x00005598da604000)
> undefined symbol: PL_thr_key
> (/usr/lib/perl5/vendor_perl/auto/Net/SSLeay/SSLeay.so)
> undefined symbol: Perl_sv_setnv_mg
> (/usr/lib/perl5/vendor_perl/auto/Net/SSLeay/SSLea
> [many more undefined symbol errors]
>
> Ævar and anyone else familiar with Perl, any ideas? The best I can get
> from the Arch forums is that this tends to occur when perl calls an
> external lib built against a different version of perl, but I can't
> tell if that's happening here.

Do you mean why does it emit a bunch of "undefined symbol" errors?
That's perfectly normal, it's because you're pointing ldd at a library
that expects symbols from libperl, since that'll be loaded first when
it's run, but the stand-alone invocation doesn't have that, I get the
same on Debian.

$ ldd -r /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/Net/SSLeay/SSLeay.so
2>&1|grep -c 'undefined symbol'
56
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libperl.so.5.24 ldd -r
/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/Net/SSLeay/SSLeay.so 2>&1 |
grep -c 'undefined symbol'
0

That by itself does not suggest the library is broken, and your
version seems to link to a working libssl.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]