Avoiding hardcoded paths when static-compiling
Hi, all: I provide an RPM package called gnupg22-static for those who need to run newer versions of GnuPG on CentOS-7 environments (it's stuck on gnupg-2.0 there). For compilation, I use the convenient STATIC=1 mechanism, but there's still the problem that all paths end up being hardcoded to the RPM buildroot environment. The full build command is: make -f build-aux/speedo.mk STATIC=1 CUSTOM_SWDB=1 INSTALL_PREFIX=. this-native In the RPM context, the INSTALL_PREFIX ends up being inside a buildroot location, like so: /builddir/build/BUILD/gnupg-2.2.17/ However, the final installation of this will be in /opt/gnupg22, which means that if a binary needs to call another binary, it will try to execute /builddir/build/BUILD/gnupg-2.2.17/bin/foo (and fail). I can't set INSTALL_PREFIX=/opt/gnupg22, because that will make the RPM build fail (it cannot write outside of /builddir), so I need a way to tell the binaries during build time that their final install path will be different than the path used during build. I am able to use gpg and gpgv this way by setting agent-program and dirmngr-program config values, but trying to make this work with gpg-wks-server fails. Any pointers on how I can make this work without hardcoding bogus build-time paths? -K ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Arch Linux impacted by new defaults in 2.2.17
Hello, I just saw the following bug reported in Arch Linux repos: https://bugs.archlinux.org/task/63147 with the title "[gnupg] 2.2.17 release is broken by design and breaks pacman". It appears Arch's packages use Web of Trust for introducing new developers by adding 3 signatures out of 5 (or 6) marginally trusted Master Signing Keys: https://www.archlinux.org/master-keys/ and thus they depend on these signatures to be there. Quoting the bug report: By default, pacman itself will try to look up keys which it does not know about yet, and download them with the master key signatures in order to validate signed packages/repositories. Would deploying WKD on archlinux.org and making signatures with --sender preserve third-party-signatures that they depend on? Kind regards, Wiktor -- https://metacode.biz/@wiktor signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD documentation (Re: Testing WKD setup?)
Am Freitag, 12. Juli 2019, 10:30:30 CEST schrieb Werner Koch via Gnupg-users:
> On Wed, 10 Jul 2019 21:47, johan...@zarl-zierl.at said:
> > ...except it isn't installed by default. Will this be part of
> > gpg-wks-client?
> Ooops. I meant gpg-wks-client. There is no gpg-wks-tool.
Thanks for the clarification.
> > won't be installed to libexec), it would still be beneficial to describe
> > the actual file system layout.
>
> You mean, where it gets installed? When running ./configure without any
> options gpg-wks-tool whill be installed under /usr/local/libexec as per
> GNU standards. Debian and other distors don't have this directory and
> install it under /usr/lib. You can of course use
Sorry, I should have separated this better from the previous sentence. What I
meant are two things:
1. If a user is ever to execute gpg-wks-client directly or through a script,
libexec should not be used: [1]
Right now I have the bizarre situation on Debian unstable that gpg-wks-server
is in /usr/bin even though it is meant to be executed by a service and not by
a user, but gpg-wks-client is located in /usr/lib/gnupg (Debian has no
libexec, I think).
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
2. It would still be beneficial to describe the actual file system layout of
the WKD.
This can either be done implicitly in the step-by-step guide ("After the call
to gpg-wks-client, 'find .well-known/openpgp' should list a directory
structure similar to this one: ..."). Or it can be documented separately on
the WKD page, also explaining different options (e.g. is there a different WKD
layout when WKD is deployed on a sub-domain, what are possible values for the
policy file) with links to the canonical reference documentation.
Cheers,
Johannes
signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD documentation (Re: Testing WKD setup?)
On Wed, 10 Jul 2019 21:47, johan...@zarl-zierl.at said: > ...except it isn't installed by default. Will this be part of gpg-wks-client? Ooops. I meant gpg-wks-client. There is no gpg-wks-tool. > won't be installed to libexec), it would still be beneficial to describe the > actual file system layout. You mean, where it gets installed? When running ./configure without any options gpg-wks-tool whill be installed under /usr/local/libexec as per GNU standards. Debian and other distors don't have this directory and install it under /usr/lib. You can of course use $(gpgconf --list-dirs libexecdir)/gpg-wks-client Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
