[OTR-dev] mingw build instructions/improvements

Jacob Appelbaum jacob at appelbaum.net
Wed Aug 22 03:37:02 EDT 2012


Hi,

I've been hacking on pidgin-otr's mingw build process. I pushed a branch
(ioerror/mingw32) that expanded on Ian's previous documentation, added a
few patches to the git tree, added hardening and now I think it's ready
for automation. Later, I think we should autoconf this entire process
and obsolete our previous work in INSTALL.mingw.

Here is a bit of musing about the cc/ld hardening options I added to the
pidgin-otr plugin Makefile.mingw file:

CC_HARDENING_OPTIONS ?= -fstack-protector-all -fPIE -Wstack-protector
-fwrapv --param ssp-buffer-size=1
LD_HARDENING_OPTIONS ?= --dynamicbase --nxcompat -pie

The good news about the LD_HARDENING_OPTIONS is the following:

  --dynamicbase	 Image base address may be relocated using
		 address space layout randomization (ASLR)
  --nxcompat  Image is compatible with data execution prevention

Do we want other linker options such as --no-seh or --forceinteg? If so,
it's pretty easy to add now.

One major difference from the Gnu/Linux targeted builds is that we don't
currently get '-z relro -z now' at link time. Do we care about the GOT
in the context of a Pidgin plugin? I think 'no' but perhaps I am mistaken?

The good news about the CC_HARDENING_OPTIONS is that we'll get ASLR in
addition to the stack smashing protection. Huzzah. Freedom through
obsolescence indeed.

Pidgin should really harden their builds. My attempts in that area have
been stalled for quite some time and I've basically given up on them:
http://developer.pidgin.im/ticket/13879

I think we want to add hardening options to all of the libraries we use
during the build process. We could easily hack up some patches for our
own build process and if they'd like it, we can send them upstream. Any
thoughts on that Ian?

All the best,
Jake



More information about the OTR-dev mailing list