[pkg-gnupg-maint] Bug#806940: Bug#806940: gpgv-static possible?

Wed Nov 9 13:48:35 UTC 2016

On Wed 2016-11-09 06:18:03 -0600, Hans-Christoph Steiner wrote:
> This is targeting Android and ChromeOS, both based on the Linux
> kernel.

Thanks for the explanation, this makes sense.

Would you take a pass at updating the final paragraph of the gpgv-static
package description that i proposed and try to make it clearer and more
suggestive of how it should be used?

>> I'm attaching a very rough proposal for how we'd make a gpgv-static.
>> But i note when using this approach, during the final linking of gpgv, i
>> see the following error messages:
>> 
>> ../common/libcommon.a(libcommon_a-stringhelp.o): In function `get_pwdir':
>> ./build-gpgv-static/common/../../common/stringhelp.c:378: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
>> ./build-gpgv-static/common/../../common/stringhelp.c:385: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
>
> Perhaps it doesn't matter?  For Lil' Debi, I built gpgv statically on
> Debian for Android, and it worked well.  But that was using the Android
> NDK, so it was not building against glibc but rather Android's bionic libc.
>
> https://github.com/guardianproject/lildebi/blob/master/external/Makefile#L123

I wasn't convinced it doesn't matter until i did some research and
testing -- the issue relates to NSS (the GNU name service switch) and
how these database lookups are implemented:

    https://sourceware.org/bugzilla/show_bug.cgi?id=348
    https://stackoverflow.com/questions/5426420/linker-warnings-while-building-application-against-mysql-connector-c-libmysqlcli

So looking at get_pwdir in common/stringhelp.c, all of those calls are
inside the get_pwdir function, wrapped in an #ifdef HAVE_PWD_H.  This
code is used for tilde(~) expansion inside do_make_filename(), which
itself is a helper function for the make_{,abs}filename{,_try}
functions.  if it's an isolated tilde, and $HOME is set, it's not used.

While the stackoverflow post claims that a statically-linked gpgv that
is built against glibc will fail at runtime if libnss_files.so (or
whatever) is not available, i've tested it locally (on debian) with a
chroot with only the following files:

     test.txt
     test.txt.sig
     keys.gpg
     gpgv-static

I even tested tilde-expansion with $HOME unset, doing:

    HOME= strace -f -T -tt -o gpgv.strace chroot . ./gpgv-static --keyring '~/keys.gpg' --keyring '~root/no-such-keyring.gpg' ./test.txt.sig ./test.txt

and i didn't see any failure.  I did see a bunch of attempts to scan for
nsswitch.conf and libnss_compat.so.2, etc [0].  If i drop the arguments
with tildes in them, then none of this scanning happens.

fwiw, if these lookups do fail, then '~' seems to be resolved to the
empty string, and '~foo' is just used literally.

Tilde expansion isn't super important -- it certainly shouldn't be used
in debootstrap.  And if the result was a crash i'd really want to find a
workaround here.  Out of curiosity, how is HAVE_PWD_H set (or unset) in
the config.h for your static build against bionic libc?

If we decide we do care about avoiding these warnings, i see two
possible approaches to research:

 a) edit configure.ac to break out the AC_CHECK_HEADERS test for pwd.h
    into a separate test that we can turn off with an argument to
    ./configure.  Then explicitly build-gpgv-static separately, and
    ensure that arg is passed to ./configure.

 b) build the gpgv-static program against dietlibc or musl, but i don't
    know whether that would work when linking against the other
    libraries' static versions, which were not built with such a
    directive.

given that the statically-built binary appears to fail gracefully in the
absence of libnss inside a chroot, though, i'm inclined to not bother
with either of these approaches.

what do other folks think?

         --dkg

[0] here's the scanning that gpgv-static does looking for GNU NSS (as
recorded by strace) if any of the arguments try to use tilde expansion:

open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000020>
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000020>
open("/lib/x86_64-linux-gnu/tls//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000026>
stat("/lib/x86_64-linux-gnu/tls/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000019>
open("/lib/x86_64-linux-gnu/tls/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000019>
stat("/lib/x86_64-linux-gnu/tls", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000017>
open("/lib/x86_64-linux-gnu//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000020>
stat("/lib/x86_64-linux-gnu/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000018>
open("/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000020>
stat("/lib/x86_64-linux-gnu", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000017>
open("/usr/lib/x86_64-linux-gnu/tls//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000018>
stat("/usr/lib/x86_64-linux-gnu/tls/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000017>
open("/usr/lib/x86_64-linux-gnu/tls/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/usr/lib/x86_64-linux-gnu/tls", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000015>
open("/usr/lib/x86_64-linux-gnu//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/usr/lib/x86_64-linux-gnu/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/usr/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/usr/lib/x86_64-linux-gnu", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/lib/tls//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/lib/tls/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/lib/tls/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/lib/tls", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/lib//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000018>
stat("/lib/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000017>
open("/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/lib", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/usr/lib/tls//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/usr/lib/tls/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/usr/lib/tls/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000016>
stat("/usr/lib/tls", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/usr/lib//libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000017>
stat("/usr/lib/", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000016>
open("/usr/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000018>
stat("/usr/lib", 0x7fffaa1772d0) = -1 ENOENT (No such file or directory) <0.000015>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161109/5862b3c8/attachment.sig>