Nobody started to hack on it in two years, and buried in this bug report nobody will find it. If this is still a desirable task, a new ticket should be opened.

and the platform is ...

The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.

You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.

A few people asked for this generic option help; it is not specific to keyservers. Now we implemented that and still not okay for everyone, oh dear.

gpg: Note: '--keyserver' is not considered an option

Option parsing stops at the first non-option. "--keyserver" and "sec1...." could have also been key specifications.
Because sometimes people make errors we print a warning. But we can't bail out on a perfectly valid command line. That is the same why

No way to fix, itself. Better warning/error message can be done.

Sorry, I thought I would receive an email when this was updated.

We don't do this on-the-fly to avoid cluttering the /run/user with directories.

So, I was expecting gnupg to use /run/user/$UID/gnupg/. However, if GNUPGHOME is
set, it uses /run/user/$UID/gnupg/d.$GNUPGHOME_HASH/. Therefore, by "littering",
I assume you mean littering /run/user/$UID/gnupg/ (otherwise this argument makes
no sense).

I'm leaving this here for future readers as I can't find *any* documentation of
this behavior (the use of d.$GNUPGHOME_HASH).

---

Regardless, my actual goal is to move the homedir to ~/.local/share/gnupg (not
have multiple homedirs) as described in (T1456)
so I really do want sockets to go in /run/user/$UID/gnupg/. However, I'm
guessing that's not going to be possible.

I have now learnt how GCC uses 'undefined behavior' for aggressive optimization
and that this could break code doing unaligned accesses even on x86. So this
needs to be fixed after all.

Sorry, this is not a help line. Please ask on the gnupg-users mailing list for help

Sorry, I have not used those conf files suffixed for a long time.

Just for the record:
It's gpg.conf-1 or gpg.conf-2 and not gpg.conf.1

My workaround for this problem also was to have a gpg.conf-2 which is then used
by gpgconf and a gpg.conf that is used by gpg 1.

gpgconf, which is a gnupg 2 tool, can't work with gpg version 1. As soon as you
use options not available in gpg 1 you will run into problems for which there
may or may not be a workaround.

The easy workaround is to use gpg.conf.1 which will be used by gpg 1 instead of
gpg.conf.

What you describe is a standard requirement for many low level libraries and
tool when cross-compiling.

Please do not use the bug tracker for discussions but use gnupg-devel instead.
Thanks.

John is using 2.1.14, but this bug was fixed in 2.1.15.

This is apparently just re-reported on gnupg-users:

https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056892.html

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

What you see is no output but diagnostic messages send to stderr.

Right. Putting armor into gpg.conf is a very bad idea. Don't assume that. If
users want to shoot into their own foot, let them do so.

I see. So, how can I reliably know whether the output of my program is going to
be ascii or binary (to append either .asc or .gpg)? I should just assume that
'armor' will not be in gpg.conf?

Sorry for not providing further infos, I did not find the time before now.
I just tested with version 1.7.2; there the problem has disappeared.

I guess this change mentioned in the change log is the relevant one:
+2016-07-01 Jussi Kivilinna <jussi.kivilinna@iki.fi>
+
+ Fix static build.
+ * tests/pubkey.c (_gcry_pk_util_get_nbits): Make function 'static'.

Thank you very much, the case can be closed.

I do consider it a bug, at least because we did not signal an error to ssh-add.
Fortunately, this was easy to fix.

Fixed in 270f7f7b.

You are welcome. If my bad English makes it difficult, here is another document.

http://web.monkeysphere.info/doc/trust-models/
You can find the explanation:

So "full" ownertrust on a key is only meaningful as long as there is a trust
path to some User ID on that key already. "ultimate" ownertrust is meaningful
anyway, because presumably you control that key.

Ok I think I get it. I appreciate you taking the time to explain it.
Thanks.

Ok I think I get it now. Thank you for explaining it to me. I appreciate it

Adding "ultimate" trust means: you are specifying it's your own key. GnuPG
doesn't check if your own key is signed by another your own key (or you really
have corresponding private key).

Let me explain the validity of public keys.

• Start with a set of key(s) with "ultimate" trust. Ultimate keys are all valid,

put them to a set of valid keys.

• Pick a key from valid keys. Collect all keys signed by this key (locally or

globally), it's all valid. Put them to a set of valid keys.

Next, it checks "full" or "marginal" trust to a public key.

• Start with the set of public keys which are valid (by the computation so far).
• Pick a key from the set. If it has "full" trust, mark all keys which are

signed by this key as it's reachable by "full" trust.

• If it has "marginal" trust, mark all keys which are signed by this key as it's

reachable by "marginal" trust adding a point.

• Scan all marked key. If it can be reachable by "full" trust. It will be in

the set of valid keys. If it can be reachable by "marginal" trust by 3
(default) different keys, it will be also in the set of valid keys.

• Add checked keys to the set of valid keys. And apply(repeat) this procedure

recursively, to the newly added valid keys. Don't repeat too far. Stop if it
goes 5 (default) times.

In other words, adding trust (by --edit-key) to a valid key makes it possible
for another key to be validated by that key. Adding trust (by --edit-key) to an
invalid key doesn't make that invalid key valid. (If it's "full" or "marginal".)

But why does marking it as ultimately trusted ignore that it was never signed?

scdaemon is part of GnuPG.
OpenSC is entirely unrelated to GnuPG.

Please take this to a mailing list (e.g. gnupg-users)

Ah sorry I understood you were saying the bug is in OpenSC. Where can I report
to scdaemon? I can't find it.

FireFox is not GnuPG and does not support the OpenPGP card.

As I said, the card may work with gpgsm because I once developed support for the
Belgian eID card. But it is likely to need some tweaking (gnupg/scd/app-p15.c)

I saw that it says not supported, but DNIe is actually supported. I can use it
flawlessly with Firefox for instance.

Please see:
https://github.com/OpenSC/OpenSC/wiki/DNIe-%28OpenDNIe%29#update-2013-08-27
https://github.com/OpenSC/OpenSC/issues/774#issuecomment-222468916

Thanks!

Given that a released version of libgpg-error does now exist, the problem should
be solved even for further versions taken from the repo.

A beta version is not a released version. For example SO numbers may be
different. BTW 1.22 has been released.

There's an issue somewhere: I built & installed libgpg-error 1.22 beta exactly
the same way as I did with 1.21. I'm not surprised by your answer: you guys have
already dismissed another perfectly valid issue report.

Something went wrong wile you installed libgpg-error. The linker picks up
another version of the library. If you need help, please ask on gnupg-devel.
Glad, that it now works for you.

libgcrypt 1.7.0 is out. Please test with it.

If I understand correctly, we cannot compile latest libgcrypt because:

• the installed libgpg-error is a beta release
• it has been installed in /usr instead of /usr/local

That's unusual.
So I rebuilt libgcrypt with libgpg-error stable 1.21 installed in /usr, and it
passed.

It is true that I have built & installed libgpg-error from git master into
/usr:
./configure --enable-shared=yes \

			--enable-maintainer-mode \
			--prefix=/usr --sysconfdir=/etc --localstatedir=/var

But what do you mean by "properly install the library"?