buildroot INSTALL_PREFIX and hardcoded paths
Hello:
I'm trying to package a static build of gnupg22 so I don't have to copy
things manually to each CentOS-7 system where I need ECC crypto support.
I'm using the following to build gnupg-2.2.8 inside the RPM:
make -f build-aux/speedo.mk STATIC=1 CUSTOM_SWDB=1 \
INSTALL_PREFIX=%{buildroot}/opt/gnupg22 this-native
RPM needs to "install" things into a buildroot, so in the above case,
%{buildroot} is /buildroot/build/BUILDROOT/gnupg22-static-2.2.8-2.x86_64.
Of course, this means that gpg and other binaries expect to call
gpg-agent, dirmngr, and other auxiliary programs in
/buildroot/build/BUILDROOT/gnupg22-static-2.2.8-2.x86_64/opt/gnupg22/bin
instead of just /opt/gnupg22.
Is there a simple solution to this? I know it's not the intended purpose
of speedo.mk, but it's convenient to use it in my case, if only I could
teach it to distinguish between where things are during build and where
they will be after installation.
Currently, I work around this by setting agent-program and
dirmngr-program in gpg.conf.
Thanks for any suggestions!
Best,
Konstantin
signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Silencing MDC Warning with gnupg 2.2.8.
On Thu, 14 Jun 2018 13:56, ra...@inputplus.co.uk said: > I see that --ignore-mdc-error downgrades the error to a warning allowing Right, this is the suggest method to decrypt old mails. > --no-mdc-warning is now a no-op and so doesn't work in concert with Right, this is on purpose. The warning is important to educate users. > remove the MDC warning from stderr, allowing the rest of stderr's > content to pass? Downstream of this command is unhappy otherwise. Why do you need stderr at all? These are diagnositics for human consumption. And, as I said, we want that the warning show ups if the override option is enabled. > gpg(1) still documents --force-mdc and --disable-mdc, saying they're now > no-ops, but --no-mdc-warning is undocumented despite still being > accepted and also a no-op. This hampers investigating why There is no reason to document a dummy option which never affected the behaviour of gpg. This is in contrast to the other mentioned NOPs. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpIY0MqKxlPm.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Silencing MDC Warning with gnupg 2.2.8.
Hi, With the arrival of gnupg 2.2.8-1 on Arch Linux this command applied to members of an archive of files on read-only media fails because they old enough not to have Modification Detection Codes. gpg -q --batch --no-mdc-warning -d --passphrase-fd 0 foo.gpg I see that --ignore-mdc-error downgrades the error to a warning allowing the decrypted content to appear on stdout, but unfortunately for me --no-mdc-warning is now a no-op and so doesn't work in concert with --ignore-mdc-error to silence the warning. It seems from skimming the source that my only option is to expect and remove the MDC warning from stderr, allowing the rest of stderr's content to pass? Downstream of this command is unhappy otherwise. gpg(1) still documents --force-mdc and --disable-mdc, saying they're now no-ops, but --no-mdc-warning is undocumented despite still being accepted and also a no-op. This hampers investigating why --no-mdc-warning isn't working. BTW, 2.2.8's `NEWS' has `--no-mdc-warn', but the option ends in `warning' and so my searches didn't find the news item. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is something not right with my ~/.gnupg/pubring.kbx
On Fri, Jun 8, 2018 at 8:21 PM, Ajax wrote: > Most gpg commands give me something like this: > > $ gpg -Kv > gpg: using classic trust model > gpg: keydb_search failed: Invalid value > gpg: Oops: keyid_from_fingerprint: no pubkey > ~/.gnupg/pubring.kbx > > Followed by what appears to me to be normal output. > > I also see: > > $ kbxutil --stats ~/.gnupg/pubring.kbx > Total number of blobs: 600 >header:1 > empty:0 > openpgp: 599 > x509:0 > non flagged: 599 >secret flagged:0 > ephemeral flagged:0 > > What should I do to clear the Invalid value and no pubkey? > > I only saw this problem after upgrading from gpg 1 to gpg2 and using the > given script to migrate from pubring.gpg to pubring.kbx. > > These outputs seem to throw a monkey wrench into some scripts such as, for > example, with pass generate -i > > This is gpg 2.1.18 atop Debian stretch and Linux 4.9.0-6-amd64, > > Thank you. > Are there no sugestions on how I should try to eliminate the indication of no pub key althoug gpg -k shows my public keys? Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Problem refreshing keys
On Wed, 13 Jun 2018 23:22:19 -0400, Phil Pennock stated: >On 2018-06-13 at 09:52 -0400, Jerry wrote: >> On Wed, 13 Jun 2018 15:25:04 +0200, Werner Koch stated: >> >The common problem on Windows: You can't use ' to quote; we Unix folks >> >always forget about that. Use > >Bah, I just didn't know. :D I suspected though, which is why I >mentioned typing interactively as a fallback. > >> gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye >> S # hosttable (idx, ipv6, ipv4, dead, name, time): >> S # 0 hkps.pool.sks-keyservers.net (216.66.15.2) >> OK >> >> Is that what it should be reporting? > >What version is it? Is there a newer version available? > > gpg-connect-agent --dirmngr "GETINFO version" /bye > >There have been a bunch of fixes for various DNS issues with dirmngr, I >would expect to see something showing that it's a pool. > >You're talking to zimmermann.mayfirst.org, which works fine; I just >overrode DNS for the pool and made sure that >hkps.pool.sks-keyservers.net only reached that IP (/etc/hosts override) >and I was able to retrieve a key fine, after which: > >> KEYSERVER --hosttable >S # hosttable (idx, ipv6, ipv4, dead, name, time): >S # 0 hkps.pool.sks-keyservers.net >S # . hkps.pool.sks-keyservers.net >S # . --> 1* >S # 1 4 216.66.15.2 (hkps.pool.sks-keyservers.net) >OK > >I suspect that you have an old dirmngr and the problems are fixed with a >newer release of gpg4win. > >-Phil gpg-connect-agent --dirmngr "GETINFO version" /bye gpg-connect-agent: no running Dirmngr - starting 'C:\Program Files (x86)\Gpg4win\..\GnuPG\bin\dirmngr.exe' gpg-connect-agent: waiting for the dirmngr to come up ... (5s) gpg-connect-agent: waiting for the dirmngr to come up ... (4s) gpg-connect-agent: connection to the dirmngr established D 2.2.7 OK I have Gpg4win Version 3.1.1 (2018-05-03) installed. That is supposed to be the latest version. -- Jerry ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
