Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.

test after system upgrades

I have enabled login again and added the following login hint:
"Login via your Roundup account on bugs.gnupg.org has been disabled due to the migration to Phabricator. We apologise for any inconvenience caused. If you have previously used your Roundup account in this wiki, you can request a new password using the link above."

• marcus (Marcus Brinkmann) <noreply@dev.gnupg.org> [20170622 16:41]:

So, the default change 7y ago and the world didn't end. Closing this.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20170317 12:57]:

Fixed with commit 69c521d.
You can reconfigure your server. Thanks.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20170316 21:12]:

What is this Apache thing ;-). Frankly, I don't have one running and it would
be easier if you can remove it from testkolab.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20170316 14:37]:

Thomas: Is there any way how I can reproduce this now that you changed the
configuration of testkolab?

Thank you.
I have removed the hint about the login problems.

Please give Bernhard and me a head-up (outside this issue) as soon as you know
which authentication method/providers you will support.

Please assign this issue to _me_ when ...

Werner, you closed this issue with (the now removed) T1448 (wk on Jun 24 2014, 01:42 PM / Roundup) stating:
"You may use --ignore-invalid-option to list options which are only implemented
by gpg2."

This option seems only to be supported in gpg.conf, not on the command line.
(but this is no problem for me)

And it generally works fine (thank you!), just not in this special case here,
becaue gpg1 accepts the option "--debug-level" as valid, but does not allow
any arguments (neither numbers nor e.g. "basic").

The result (with "debug-level basic" in line 42) is:

$ gpg
gpg: /home/thomas/.gnupg/gpg.conf:42: argument not expected

I'm currently using gpg (GnuPG) 1.4.18 from Debian jessie.

As I understand it, "debug-level" is intended to just be a dummy option in
gpg1 to avoid problems with this option appearing in gpg.conf, correct?
So we have two possible solutions:

• either remove option "debug-level" (and rely on "ignore-invalid-option debug-level")
• or accept an argument for "debug-level"

OK, I don't care enough to warrant more discussion/work on this.
"Unknown elliptic curve" is already better than "Invalid elliptic curve".

ah, misread the 2.1.16 part, so yes, it seems to be fixed.

Where do you take it from that keyid-format none should result in the full
fingerprint being shown?

The man page:
"none" does not show the key ID at all but shows the fingerprint in a separate
line.

OK, then this is just an issue for interactive usage, but still an issue.

To be clear: I want the

• less specific and
• already existing

error message "Unknown algorithm" (instead of "Unknown elliptic curve", which is
not correct in too many situations)

Regarding the original issue discussed here:
What about an option in gpg/gpgme to limit all operations to keys contained in a
"whitelist" file?

(accept --recipient keys only if they are contained in the file, --list-keys
shows only keys listed in this file, --refresh-keys only refreshes keys listed
here, etc.)

Reported the problem mentioned here in T2835
("keyid-format none" ignored for --verify and other commands)

(repost, I just noticed that neal is not in the nosy list. I'll unlink the old
entry afterwards)

neal: Interesting idea, this (or for a non-gui version: a signed list of
fingerprints available from a central source and retrieving those keys) would
solve 2 (iterating over all keys) and 3 (regularly update).

For the non-gui variant I wondered about how to use --verify and check that the
file was signed by the authority key (--verify only prints the keyid,
"--keyid-format none" does not allow --verify to print fingerprints in 2.1.15,
I'll file a separate issue). I was a bit disappointed when I saw that gpg sync
just calls the command line with --keyid-format 0xlong and does screen scraping
to verify the verification.

But still, how to solve 1 with gpg itself? Of course I could "manually" verify
in the application that only the intended keys have been used, but as shown with
gpg sync's code above: This is not always easily possible.

Sign the keys and set the signing key to fully trusted.

does not solve 1.:

Encrypt a file to any of those key (but no others!),

(because people may trust other keys)

and it does not solve 2. without keeping a separate list of keys/fingerprints:

Iterate over all keys

additionally _all_ users have to regularly update _all_ these keys, otherwise
things like expired subkeys will lead to failing encryption. (This is no theory:
We've been there and don't want to have this again)

The string "Unknown algorithm" already exists. Because it is less specific, it
does not indicate that there is a problem regarding support for elliptic curves
here.

Please tell me how I should model my workflows in this case:

• There is a a centrally managed set of public keys (currently in a keyring

file, but I'm open to suggestions)

• Different users should be able to use this set of keys (and no others) for

certain tasks:

1. Encrypt a file to any of those key (but no others!), but also decrypt the

file with their secret key (which is not centrally managed)

2. Iterate over all keys and do something with them (here: publish them in the

WKD after having made changes to the set of keys)

A little bit better, but that would still confuse me, as I did not intentionally
specify an elliptic curve.
What could help here is:

1. talking about algo/algorithm (that is shown in the man page as parameter for

--quick-gen-key)

2. saying which algorithm gpg saw.

If the error message had been "Unkown algo 'user@example.com'" I would
immediately know that I provided an email address where an algorithm was expected.

Andre said, category dirmngr is better

Ah, I understand. I currently have two keyrings (the default keyrings and
debian-keyring.gpg) in my user account. So I will export the keys from
debian-keyring.gpg and import them into my regular keyring.

But this is a different topic from the one described here:
This issue is about allowing gpgme to use exactly one different keyring (not an
additional keyring) that is different from the default keyring or other keyrings
configured in the user's gpg.conf.

So it is just about allowing in gpgme what is already possible via the command
line. Or maybe you would prefer to allow passing command line options to gpg via
gpgme to avoid the wrapper script mentioned below?

Besides the WKD scenario Andre describes, there are already many existing uses
of a separate keyring where having other keyrings configured via
~/.gnupg/gpg.conf already conflicts with the intended use, except when using
--no-options:

1. /etc/apt/trusted.gpg
2. /usr/share/keyrings/debian-keyring.gpg
3. our company's keyring with acceptable keys for encryption of certain

sensitive information

Basically everywhere where multiple users use a single keyring, often with
"--trust-model always", where you do not want additionally configured keyrings
to disturb the result and give a false sense of security.

Please explain why this a Bad Thing[tm] and what the correct workflow would be.

Another small note: The problematic key was in wide-spread use and additionally
it was distributed until few years ago with Apache's KEYS file and still is
listed here: https://people.apache.org/keys/committer/lars.asc

And I would not call my keyring "very large", it contains less than 1700 keys,
mostly fetched using "keyserver-options auto-key-retrieve" when reading mailing
lists.

So it probably does not only affect me.

Two more details:

1. All secret keys become unusable in this situation until you revert to a

backup of the public keyring, therefore I propose status "critical" (data loss)

2. The duplicates (or even triplicates with my own keyring) of the keys only

have one uid, even if the original has more.

strange thing is that this works with pinentry-qt

These are the versions in Debian squeeze.
The same happens with gnupg 2.0.17 and pinentry 0.8.0, we have not tested 0.8.1 yet.

Confirmed with different user accounts and window managers (KDE, stumpwm, ...).
The qt3 version works without problems.

I did not have a chance to test 2.0.17 or the patch yet, but for the archive:
I just have an instance of gpg-agent, which does not allow ttys matching
"/dev/pts/??", i.e. two digits. On three-digit-ttys it works. Maybe the
behaviour depends on the length of tty when the gpg-agent was started first or
something similar.

From http://gnupg.org/download/cvs_access.en.html:
the stable 2.0 version (currently version 2.0.16) is known as STABLE-BRANCH-2.0;
the stable 1.4 version of GnuPG (1.4.11) is known under as STABLE-BRANCH-2.0.
I guess I should look at the first of the two :)

Sounds good. I'll test it as soon as we have a kk package for the next release.

Hallo Werner!

Today I just had the problem again (/dev/pts/9, still same verisons as in T1203 (thomas on Jul 29 2010, 03:35 PM / Roundup))

Just had the problem on /dev/pts/9 while no problems since 2010-07-29 (because I
usually start mutt in a certain screen window where I made sure that it has a
high-enough tty number)

Still a problem with gnupg-agent 2.0.14-0kk2 and pinentry (or pinentry-qt in
curses mode because of unset $DISPLAY) 0.7.6-0kk1 on Debian lenny:
Does not work on /dev/pts/7, works on /dev/pts/72

Your logs show /dev/pts/7 and as I wrote in T1203:
other bug reports indicate that any /dev/pts/(single-digit) exposes the problem.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20100317 16:00]:

Werner Koch <wk@gnupg.org> added the comment:

What pinentry version are you using (qt or another one)?

Upgrading from 2.0.7.svn4643-0kk1 and from 2.0.7-1kk2 to 2.0.8-0kk1 worked fine.
(tested on two machines, both having a running gpg-agent and then decrypting
OpenPGP and S/MIME messages)