Your home is under /dev/ - really? Please run

Okay I think I got the root of the issue

When I did

brew reinstall gpg2

I saw this today

In T2203#88661, @nuimk wrote:

/usr/local/bin/gpg-agent -v --daemon

I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.

First let me say that it is never a good Idea to use outdated / unmaintained security software. PGP Messages are external input and you pass that to unmaintained software.

Fair enough. Let's wait and see what others think.

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.

There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.

I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.

I don't see a problem. If you have the private key you can and will use it. I guess your concern is an oracle?

The platform is illumos, a fork of OpenSolaris.

No response.

No. But as of 3.0 GpgOL for Outlook 2003 and 2007 is no longer maintained and the support for this will be removed in some future version. This bug only affects new installations of GpgOL on the unmaintained (by Microsoft) Outlook 2003 and Outlook 2007 Versions. So -> Wontfix.

@aheinecke did you change the default?

werner says it's not a bug.

I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.

--with-fingerprint is an option to modify the output of --list-keys and not a command. There are other --with-xxxx options for other purposes. There is no command to list a keyring. This is why gpg meanwhile prints a warning when used without a command.

I don't think anyone is suggesting the use of gpg without a command. However, use WITH the --with-fingerprint command seems to be broken. Thank you for providing a correct way of doing what we want, but please either explain why the use of the --with-fingerprint command isn't working, or put this back as a bug.

The use of gpg without a command is simply wrong. This has never been specified and could actually lead to surprises.
You need to import the key first and then look at it with -k (--list-keys) or --fingerprint.

or am i missing something here?

Solution has been given: Use "gpg.conf-1" for gpg 1.4

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.