Re: [Fetchmail-users] OAUTH2 Dilemma (getting off topic)

[Dennis P. <da...@be...>]

On 3/30/2022 3:51 AM, Matthias Andree wrote:
> Am 29.03.22 um 17:09 schrieb Dennis Putnam:
>> On 3/27/2022 7:42 AM, Matthias Andree wrote:
>>> Am 26.03.22 um 21:20 schrieb Dennis Putnam:
>>>> It appears Fetchmail 7 requires TLS 1.3. I am running CentOS 7 and the
>>>> support folks tell me that RedHat does not intend to add TLS 1.3 to
>>>> CentOS. I wonder if it will be added to RHEL? Anyway, that means I am
>>>> stuck using Fetchmail 6 for the foreseeable future. Before I go to the
>>>> trouble, do the OAUTH2 patches for Fetchmail 6 also require TLS 1.3?
>>>> TIA.
>>>>
>>> Dennis,
>>>
>>> that's a bit of a letdown although I understand that in a stable CentOS
>>> 7 series they don't want major changes, and TLS v1.3 in itself is one,
>>> so you are stuck between a rock and a hard place... but you can work
>>> yourself out of this.
>>>
>>> You can install the latest OpenSSL 3.0.x to a separate directory,
>>> WARNING UNTESTED because I do not have CentOS 7,
>>> but somewhere along the lines of but maybe needs tweaking:
>>> unpack OpenSSL 3.0.x, then
>>> ./config --prefix /opt/openssl3 --openssldir=/usr/lib64
>>> -Wl,-rpath=/opt/openssl3/lib
>>> -- and then point your fetchmail 7 alpha build there to use it, with
>>> ./configure --with-ssl=/opt/openssl3
>>>
>>> The additional burden on you will then be to watch future OpenSSL 3.0.x
>>> releases and upgrade your /opt/openssl3 should security fixes become
>>> necessary in some future OpenSSL version, so take notes of what worked
>>> for you if you had to tweak things.
>>>
>>> Hope that helps.
>>> Matthias
>>>
>>>
>>
>> Hi Matthias,
>>
>> Quick question about --openssldir=/usr/lib64. Isn't that where openssl
>> 2 also lives? Won't that result in either overwriting or a conflict?
>
> Hi Dennis,
>
> First, I should say that it is to be --prefix=/opt/openssl3 (the =
> matters). Sorry about that.
>
> Then, about the openssldir, it seems that OpenSSL 3.0.2 would only
> install "*.cnf.dist" files (for ct_log_list.cnf and openssl.cnf) and
> then copy them to the real "*.cnf" if missing or otherwise let them
> alone. Also check if it's right for you.
> The plan is to share existing configuration so the certificate bundle
> and other trust stores are shared.
> Note I adapted the above in a web reference to CentOS, but I don't have
> CentOS myself; for Fedora Linux and I think on the Debian-based distros
> (including Ubuntu and derivatives) too, I would have to use
> --openssldir=/etc/pki/tls instead.
>
> Regards,
> Matthias
>
>
Hi Matthias,

Openssl 3 seemed to install correctly or at least it passed 'make test'. 
However, I am not able to run it as I get this:

 >/opt/openssl3/bin/openssl version
/opt/openssl3/bin/openssl: error while loading shared libraries: 
libssl.so.3: cannot open shared object file: No such file or directory

It appears a library did not get built or put in the right place. Unless 
I am missing a prereq but then I would have expected the test to have 
failed.