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
signature.asc
Description: PGP signature
