Re: Supporting Windows SChannel as OpenSSL replacement
От | Heikki Linnakangas |
---|---|
Тема | Re: Supporting Windows SChannel as OpenSSL replacement |
Дата | |
Msg-id | 53EE4158.2030506@vmware.com обсуждение исходный текст |
Ответ на | Re: Supporting Windows SChannel as OpenSSL replacement (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Supporting Windows SChannel as OpenSSL replacement
|
Список | 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 по дате отправления: