On Tue, Sep 24, 2019 at 11:52:48PM +0200, Peter Eisentraut wrote:
> That's not actually what this file looks like in the upstream release.
> It looks like the packagers must have patched in the protocol codes for
> TLS 1.1 and 1.2 themselves. Then they should also add the corresponding
> SSL_OP_NO_* flags. AFAICT, these pairs of symbols are always added
> together in upstream commits.
Yes, they did so. I see those three fields as of 6287fa5 from
upstream which is the release tag for 0.9.8j:
#define TLS1_VERSION 0x0301
#define TLS1_VERSION_MAJOR 0x03
#define TLS1_VERSION_MINOR 0x01
However if you look at the top branch OpenSSL_0_9_8-stable (7474341),
then you would notice that ssl/tls1.h does something completely
different and defines TLS_MAX_VERSION. So everything is in line to
say that the version of OpenSSL in SUSE labelled 0.9.8j is using
something compatible with the latest version of upstream 0.9.8zi. I
think that we should just stick for simplicity with the top of their
branch instead of trying to be compatible with 0.9.8j because Postgres
12 has not been released yet, hence if one tries to compile Postgres
12 with OpenSSL 0.9.8j then they would get a compilation failure, and
we could just tell them to switch to the latest version of upstream
for 0.9.8. That's something they should really do anyway to take
care of various security issues on this branch. Well, if that happens
they should rather upgrade to at least 1.0.2 anyway :)
So I agree with the proposal to rely on the presence of
TLS_MAX_VERSION, and base our decision-making on that.
--
Michael