Re: Supporting Windows SChannel as OpenSSL replacement - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Supporting Windows SChannel as OpenSSL replacement
Date
Msg-id 53EE4158.2030506@vmware.com
Whole thread Raw
In response to Re: Supporting Windows SChannel as OpenSSL replacement  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Supporting Windows SChannel as OpenSSL replacement
List pgsql-hackers
On 08/15/2014 08:16 PM, Jeff Janes wrote:
> On Tue, Aug 12, 2014 at 10:52 AM, Heikki Linnakangas <
> hlinnakangas@vmware.com> wrote:
>
>> On 08/06/2014 08:37 PM, Jeff Janes wrote:
>>
>>> But now it looks like 0002 needs a rebase....
>>
>> I've committed the refactoring patch, and here's a rebased and improved
>> version of the Windows SChannel implementation over that.
>
> On MinGW, I get the following error when compiling with options
> --host=x86_64-w64-mingw32 --without-zlib:
>
> be-secure.c: In function 'secure_open_server':
> be-secure.c:106:2: error: 'Port' has no member named 'peer_cn'
> be-secure.c:106:2: error: 'Port' has no member named 'peer_cn'
> make[3]: *** [be-secure.o] Error 1
> make[2]: *** [libpq-recursive] Error 2
> make[1]: *** [all-backend-recurse] Error 2
> make: *** [all-src-recurse] Error 2
>
> Should the ereport DEBUG2 be inside the "#ifdef USE_SSL"?

Yeah.

I've been thinking though, perhaps we should always have the ssl_in_use, 
peer_cn and peer_cert_valid members in the Port struct. If not compiled 
with USE_SSL, they would just always be false/NULL. Then we wouldn't 
need #ifdefs around all the places that check hose fields either.

- Heikki




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Minmax indexes
Next
From: Robert Haas
Date:
Subject: Re: 9.5: Memory-bounded HashAgg