2

I have question compiling libpq on windows (VS2010 32 and 64bit) with SSL support. I downloaded the latest source of postgres and also the OpenSSL Win64 v1.0.1c. I ran nmake in libpq folder:

cd postgresql-9.2.2\interfaces\libpq

nmake /f win32.mak CPU=AMD64 USE_SSL=1 SSL_INC=C:\OpenSSL-Win64\include SSL_LIB_PATH=C:\OpenSSL-Win64\lib

Then the compile ends up, that he can not found bufferoverflowU.lib. Searching a bit i found out, that this lib is deployed with the windows SDK and since VS 2005 not needed anymore (see Vista / Win 7 SDK bufferoverflowu.lib linking error ). So in libpq's make file (win32.mak:20) i commented out the line

ADD_SECLIB=bufferoverflowU.lib

and it compiles fine. I also didn't get any troubles testing this libpq with ssl, yet.

Do I need to have a bad conscience droping bufferoverflowU.lib from the build or is it just because the makefile is not for VS 2010? (Btw: openssl has changed thier names of libs to *MD.lib respectively *MT.lib in VC folder. The old named libs are in C:\OpenSSL-Win64\lib, one dir up)

Can someone tell me if bufferoverflowU.lib is required in a VS2010 build?

Cheers, 550

Community
  • 1
  • 1
550
  • 1,070
  • 1
  • 13
  • 28
  • Nobody knows!? I have to correct myself: The bufferoverflowU.lib is only requested in a 64bit compile (by win32.mak makefile with flag CPU=AMD64), not for 32 bit compile (CPU=i386). – 550 Jan 18 '13 at 09:59
  • Did Postgres pass its self tests (`make check`)? If so, I would say its not needed. Also, the developers are very helpful. You can engage them directly at [pgsql-hackers](http://www.postgresql.org/list/). – jww Dec 01 '13 at 03:39

1 Answers1

1

Can someone tell me if bufferoverflowU.lib is required in a VS2010 build?

No, it's no longer necessary. bufferoverflow.lib and friends were pushed into the code that checks the stack cookie. See this KB: You may receive the "Linker tools error LNK2001" error messages when you build source code by using the Win32 Software Development Kit (SDK) or the Windows Server 2003 Driver Development Kit (DDK) for Windows Server 2003 Service Pack 1.

I believe you can make the issue go away and harden your executables with the /GS switch.

nmake /f win32.mak CPU=AMD64 USE_SSL=1 SSL_INC=C:\OpenSSL-Win64\include
SSL_LIB_PATH=C:\OpenSSL-Win64\lib

You should consider adding all the switches discussed at Protecting Your Code with Visual C++ Defenses. Here is the list in case you are pressed for time:

  • /GS
  • /SafeSEH
  • /NXCompat
  • /DynamicBase

Additionally, you should #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1 if possible. Finally, you should also add #pragma strict_gs_check(on) to high risk source files on Windows. It should be used sparingly, but is recommended in high risk situations, such as when a source file parses input from the internet.

Its common that *nix projects miss the security switches on Windows. I call it a "disconnect", and I've seen it go both ways (*nix -> Windows and Windows -> *nix). Everyone can't be an expert at everything ;)

(Sorry about wandering a bit. Bad project setups are a pet peeve of mine).

jww
  • 97,681
  • 90
  • 411
  • 885