gen-posix-lock-obj for iOS

[Chris Ballinger]

It just seems strange to me to move so much functionality into a "small
library that defines common error values for all GnuPG components".

This change drastically complicates my build, and I fear that if someone
else unaware of this change accidentally includes the wrong headers (e.g.
i386 on x86_64) this could potentially lead to unexpected security problems.

Here is the current set of scripts I use for building libgpg-error,
libgcrypt, and libotr:

* https://github.com/ChatSecure/OTRKit/blob/master/build-libgpg-error.sh
* https://github.com/ChatSecure/OTRKit/blob/master/build-libgcrypt.sh
* https://github.com/ChatSecure/OTRKit/blob/master/build-libotr.sh

As you can see towards the end of the script, after each architecture is
built, it copies a single version of the headers for that library to a
"dependencies" folder that contains the "fat" versions of the libraries.

I will need to rework these scripts to keep the headers in their
architecture-specific folder and ensure that libgcrypt isn't using
libgpg-error headers for the wrong arch.

Perhaps instead of throwing up a warning during configure if you detect the
wrong arch, throw a full error? I'm not familiar with what exactly these
values are used for, and the security consequences if the wrong values are
used on the wrong platform.

If these values are platform-specific and can only be generated at runtime
on the target architecture, why not just generate them at runtime instead
of during the configure phase?


On Tue, Sep 23, 2014 at 8:23 AM, Werner Koch <wk at gnupg.org> wrote:

> On Mon, 22 Sep 2014 22:00, chris at chatsecure.org said:
>
> > The problem with that method, is I can't do that when integrating with
> > Xcode. I have to choose a single set of headers to use for all of the
> > architectures (i386, x86_64, armv7, armv7s, arm64 / aarch64). Apple does
> a
> > lot of #ifdef magic for their own system headers to workaround this
> issue.
>
> I do not understand why it is a problem to install external libraries
> (e.g. libgpg-error, libgcrypt, gpgme) into system specific directories.
> You can always use -I and -L to tell the compiler where to look for
> header and libraries first.  In fact the gpg-error-config script as well
> as other config scripts and pkg-config templates help to keep track of
> those options.
>
> If you really don't like it, you hack around it by writing your own
> ligpg-error.h wrapper like
>
>   #if defined(__x64_64__)
>   # include "/usr/local/foo/x64_64/libgpg-error.h"
>   #elif ...
>
> and make sure that /usr/local/foo/x64_64/ is never passed as -I options.
> But for libs you would need to adjust the linker scripts (in case the
> OSX ld(1) uses such a thing).
>
> > If possible I'd like to avoid anything actually using these
> > architecture-specific options because I cannot guarantee that the correct
>
> Actually this has been used for years.  For example gcrypt.h has a
> system specific socklen_t and sys/select header.  gpgme.h uses system
> specifics types for ssize_t and off_t.  The system specific parts in
> gpg-error.h are just more noticeable.
>
> Merging them all into one header is something Apple can do because they
> control the environment and do not need to be portable to anything else.
> However, we have already seen how fragile this is if you look at the
> stdint.h problem.
>
> With the dozens of different architectures and OSes we support, the
> header files won't be maintainable.  We do the configure runtime testing
> to figure out the parameters of unknown operating systems and thus are
> able to build and run software on systems we have never seen before.
> Doing all that configure magic in an installed header file is simply not
> possible.
>
> > headers will be used, no matter how much I massage the toolchain. Is this
> > new API used heavily by libgcrypt or is it unused when compiling with
> > pthreads support?
>
> It is currently being used by GnuPG 2.1 but the next libgcrypt version
> will also take advantage of it.  Some more shared code will be moved to
> libgpg-error in the future.
>
>
> Shalom-Salam,
>
>    Werner
>
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140923/70ac31b7/attachment-0001.html>