- User Since
- Mar 27 2017, 4:49 PM (348 w, 1 d)
Feb 15 2020
Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.
Feb 14 2020
Jun 14 2018
test after system upgrades
Aug 16 2017
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."
Jun 22 2017
- marcus (Marcus Brinkmann) <email@example.com> [20170622 16:41]:
So, the default change 7y ago and the world didn't end. Closing this.
Mar 20 2017
- Werner Koch via BTS <firstname.lastname@example.org> [20170317 12:57]:
Fixed with commit 69c521d.
You can reconfigure your server. Thanks.
Mar 17 2017
- Werner Koch via BTS <email@example.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.
Mar 16 2017
- Werner Koch via BTS <firstname.lastname@example.org> [20170316 14:37]:
Thomas: Is there any way how I can reproduce this now that you changed the
configuration of testkolab?
Mar 15 2017
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.
Mar 14 2017
Please assign this issue to _me_ when ...
Nov 25 2016
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: /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"
Nov 15 2016
OK, I don't care enough to warrant more discussion/work on this.
"Unknown elliptic curve" is already better than "Invalid elliptic curve".
Nov 14 2016
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
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
(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
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
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
Nov 10 2016
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
- 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)
- 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:
- talking about algo/algorithm (that is shown in the man page as parameter for
- saying which algorithm gpg saw.
If the error message had been "Unkown algo 'email@example.com'" I would
immediately know that I provided an email address where an algorithm was expected.
Nov 9 2016
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?
Nov 8 2016
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
- our company's keyring with acceptable keys for encryption of certain
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.
Jul 4 2015
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
So it probably does not only affect me.
Two more details:
- 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)
- The duplicates (or even triplicates with my own keyring) of the keys only
have one uid, even if the original has more.
Oct 10 2011
strange thing is that this works with pinentry-qt
Sep 28 2011
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.
Sep 19 2011
Confirmed with different user accounts and window managers (KDE, stumpwm, ...).
The qt3 version works without problems.
Jan 28 2011
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
Jan 11 2011
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 :)
Jan 10 2011
Sounds good. I'll test it as soon as we have a kk package for the next release.
Oct 21 2010
Oct 15 2010
Sep 23 2010
Sep 13 2010
Aug 27 2010
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)
Jul 29 2010
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
May 21 2010
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.
Mar 17 2010
- Werner Koch via BTS <firstname.lastname@example.org> [20100317 16:00]:
Werner Koch <email@example.com> added the comment:
What pinentry version are you using (qt or another one)?
Jan 18 2008
Jan 7 2008
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)