Re: Missing include <openssl/x509.h> in be-secure-openssl.c?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, 近藤雄太 <kondo@sraoss.co.jp>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, buildfarm@sraoss.co.jp
Date: 2021-11-04T13:54:07Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Nov 03, 2021 at 11:45:26PM -0400, Tom Lane wrote:
>> Yeah, I noted the comment about WIN32_LEAN_AND_MEAN in the
>> stackoverflow thread too ... but as you say, it seems like
>> that should make the problem less probable not more so.
>> Still, it's hard to think of any other relevant change.

> Yeah, I don't see how this could be linked to WIN32_LEAN_AND_MEAN.

According to that stackoverflow thread, the unwanted #define of
X509_NAME comes from <wincrypt.h>, and WIN32_LEAN_AND_MEAN
prevents that from being immediately included by <windows.h>.

The rough idea I have is that prior to 8162464a2, we sucked in
that #define during postgres.h and then OpenSSL's headers were
able to undo it.  After 8162464a2, we don't read <wincrypt.h>
during postgres.h, but some *other* header that be-secure-openssl.c
is including after the OpenSSL headers is pulling it in, so that
by the time we get to the body of the file the unwanted #define
is active.

I don't have either the resources or the interest to track down
exactly where that happens; my thought was just to make
be-secure-openssl.c's inclusions look more like fe-secure-openssl.c.
But, if you'd like to pursue the details, feel free.

			regards, tom lane



Commits

  1. contrib/sslinfo needs a fix too to make hamerkop happy.

  2. Second attempt to silence SSL compile failures on hamerkop.

  3. Blind attempt to silence SSL compile failures on hamerkop.