[Pidgin] #15290: Compile everything with secure flags

[Pidgin]

#15290: Compile everything with secure flags
-------------------------------------+------------------------------
 Reporter:  DrWhax                   |       Owner:  datallah
     Type:  defect                   |      Status:  closed
Milestone:  2.10.7                   |   Component:  winpidgin (gtk)
  Version:  2.10.6                   |  Resolution:  fixed
 Keywords:  security aslr dep build  |
-------------------------------------+------------------------------

Comment (by noloader):

 Replying to [comment:14 datallah]:
 > Replying to [comment:13 noloader]:
 > > Replying to [comment:12 datallah]:
 > > > These changes make our crash reporting stack traces useless (I
 assume it is the ASLR that is problematic).  I'm not sure if there's going
 to be an easy way to fix that.
 > > Hmmm... I've never heard that one (I'm not being a smart ass).
 Optimizations and stripping symbols usually causes this problem. What is
 Pidgin using for crash reporting?
 >
 > The only compiler changes are the the additions to
 `CC_HARDENING_OPTIONS` and the linker changes are `LD_HARDENING_OPTIONS`
 in [d9ebf57cd361].
 > The way things are being stripped hasn't changed either.
 >
 > We're using a [https://hg.pidgin.im/util/drmingw/ forked version] of the
 drmingw `exchndl.dll` which uses the binutils bfd library to get at the
 debug symbols.
 OK, I had a chance to take a brief look at exchndl.dll.

 I think exchndl.dll is doing too much in DllMain (via OnStartup), and I
 would expect Pidgin to see some intermittent problems. I don't see where
 its safe to call SetUnhandledExceptionFilter in DllMain. "DllMain : a
 horror story,"
 http://blogs.msdn.com/b/oleglv/archive/2003/10/28/56142.aspx; "DllMain and
 life before birth,"
 http://blogs.msdn.com/b/oleglv/archive/2003/10/24/56141.aspx.

 By calling SetUnhandledExceptionFilter on the thread that calls DllMain,
 the library is actually installing the exception handler on a thread
 created by the loader. The thread dies after loading.
 http://www.oldschoolhack.de/tutorials/seh.pdf.

 exchndl.dll is also manually duplicating a lot of functionality offered in
 Debug Help. Debug Help is written by the folks who write WinDebug (and
 they are they folks who write the OS). I've had a lot of success over the
 years with Debug Help and its fully redistributable (the only drag is you
 have to download the entered SDK to get the library).
 http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms679309(v=vs.85).aspx.

 > If there were something better, we'd be happy to use it.
 You are in a sticky situation. As a project maintainer, you are bringing
 in components that you are responsible for (the project is responsible for
 its Supply Chain and outside code falls within those bounds). You can file
 bug reports upstream, but its no consolation when Pidgin takes a bug
 because upstream does not suffer Pidgin bugs. Personally, I have aversions
 to the "let's use library X" because I don't want to be responsible for
 library X (the Boost fan club is especially loud).

 With that said, have you considered google-breakpad
 (http://code.google.com/p/google-breakpad/). It claims to be an open-
 source multi-platform crash reporting system. Its under a BSD style
 license, which is fairly permissive. I know the code has a few issues from
 a quick scan of some of the sources (for example, DLL Hijacking or Binary
 Planting), but the issues should be fixed soon.

 You also have Windows Error Reporting (WER) on the Windows platform
 (http://msdn.microsoft.com/en-us/library/windows/hardware/gg487440.aspx).

-- 
Ticket URL: <https://developer.pidgin.im/ticket/15290#comment:15>
Pidgin <http://pidgin.im>
Pidgin