[Ur] openid fails to build on OS X

austin seipp as at hacks.yi.org
Sat Jul 16 18:01:12 EDT 2011


Hi,

The latest OpenID trunk (hg rev 72e942423f26) fails to build on Mac OS
X. This is due to an ignored attribution in combination with -Werror:

$ make
... snip ...
...
cc1: warnings being treated as errors
openid.c:572: warning: ‘optimize’ attribute directive ignored
make[1]: *** [openid.lo] Error 1
make: *** [all-recursive] Error 1
$

This is due to Robin Green's (CC'd) change (hg rev 00c8f43be8b7) which
introduced a secure comparison function to be used with HMACs. The
reason this fails is because the 'optimize' attribute was only
introduced in GCC 4.4, while OS X is stuck with GCC 4.2.1 (due to
licensing issues wrt GPLv3. This isn't going to change anytime soon.)
Clang does not support this construct either, and it's unlikely it
will any time soon (it seems rather rare.)

Robin, while I understand the principle behind the secure comparison
function (to avoid a timing attack based on string length,) is there a
particular reason you need GCC to optimize at level 0? Or is it just
the fact you don't want anything happening under your nose? The
assembly generated in either case is actually a bit longer than I
expected and I didn't check in all that much detail, but presumably I
missed something.

To fix this I attempted to stick the comparison function into a
seperate C file and library compiled with -O0 (made with
noinst_LTLIBRARIES in Makefile.am,) but I couldn't get autoconf to
properly override the default -O2 setting for CFLAGS, so the higher
optimization setting won out by default.

I don't know the necessary autoconf-fu in order to fix such a build
error, at least not while retaining the original things Robin wanted
(the guarantee the compiler doesn't do anything tricky.) We could just
hide such an attribute on non-GCC compilers with #ifdef-ery. This is
probably the easiest and simplest route. I guess Adam/Robin are
probably in the best positions to decide.

Alternatively, such a function could be written rather easily in
x86/amd64/whatever assembly language using inline ASM - we would never
need to speculate about what the C compiler may do. I'd be willing to
make this change but I don't think anybody is going to prefer that
option honestly. It's also not portable, but it'll work on compilers
older than GCC 4.4 (and clang) at least.

-- 
Regards,
Austin



More information about the Ur mailing list