Re: [Fetchmail-users] OAUTH2 Dilemma

[Matthias A. <mat...@gm...>]

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