- User Since
- Mar 27 2017, 4:49 PM (226 w, 4 d)
bug has been closed as Wontfix [..] I see no reason to continue the discussion in the bugtracker.
Wed, Jul 28
It is now over 10 months that the proponents of these additions have not followed up on the discussion.
dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.
Tue, Jul 27
Reading the mozilla entry more carefully, there still seems to be an issue.
@kaie, thanks for the pointer!
Sat, Jul 24
Using GPGME is probably the best way, even if gpgme-json might also work for some operations.
Wed, Jul 21
ok i found it just add "trust-model always" in gpg.conf
Hmm your log does not seem to indicate that the key is requested by GnuPG,
e.g. something like
rmngr[6077.5]: DBG: chan_5 <- KS_GET -- =email@example.com
is missing. If gpg does not ask for it, dirmngr cannot provide it. So the question is: why isn't gpg asking for the key of an email address in your setting.
Tue, Jul 20
i dont have one what shoud i put in it
Tried it myself, getting the pubkey seems to work here.
Debian gnupg Version: 2.2.27-2~bpo10+1
Mon, Jul 19
Did you try "--auto-key-retrieve"?
Fri, Jul 16
Can you show the output of the command that works and the command that does not (and gets called by evolution),
please also add a "-v" to the options.
It could also be a problem of the keyserver (some hagrid instances are known to deliberately break RFC4880), can you try with a different keyserver, e.g. http://keys2.andreas-puls.de/.
Tue, Jul 6
Jun 17 2021
Jun 15 2021
@FloorVeil thanks for testing!
There is another report that it works in 3.1.16 again in
Jun 14 2021
Jun 11 2021
May 21 2021
Could make --multifile work on windows 10, documenting the workaround here.
Apr 23 2021
I've also suggested 3.1.14, but the changelog for 3.1.15 lists two potential important defects fixed for GPGOL (the empty recipient and the auto-retrieve).
https://wiki.gnupg.org/Gpg4win/RunAsUser has more explanation about this, and I had to give this to quite a number of people in support. (An improvement to the could be a link to a very good external or official explanation, does somebody know one? I've searched briefly but was not successfull to find strong recommendations by Microsoft.)
Mar 16 2021
@werner should the pros and cons of mkportable be discussed here or on a mailinglist?
A second report came in via https://wald.intevation.org/forum/forum.php?thread_id=2044&forum_id=84&group_id=11
Mar 9 2021
Mar 3 2021
(For completeness, people don't know if there was no documentation change, so if anything strikes them as strange, they cannot say if this is because they don't have the right version of the documentation.)
Feb 26 2021
Feb 1 2021
to explain a bit more: This report was opened after the reported defect was already fixed.
As we are getting many reports and technical suggestions, please keep the reports focused on one point only if possible
and open general discussion points about development improvements on gnupg-devel@.
Jan 29 2021
Jan 19 2021
Can you point me to a more elaborate list of the general concerns? (Central directories offer some sort of stable history, namespace and API service towards identifying modules, just like the venerable https://www.ctan.org/ . The solutions built on such services, like programming environment specific "package" and dependency managers that download and install thousands of packages automatically (like yarn) may be debatable, but I am not aware of much general concern against the services itself.)
@werner, that is a missunderstanding:
Jan 18 2021
I may attempt an update here, who has the pypi maintenance account?
(If we don't have it, we need to ask Justin or create a ticket with the PSF.)
Jan 15 2021
Jan 13 2021
Jan 7 2021
The user reported to
Jan 5 2021
|we do it for the other bindings as well.|
can you elaborate?
Dec 9 2020
A backtrace with gdb from migw-w64 results in
I did a fresh install of Gpg4win 3.1.14 and imported my standard pubkey, by using
gpg --locate-key firstname.lastname@example.org
on the command line.
Nov 30 2020
@s7r Thanks for testing and letting us know!
Nov 18 2020
Thanks Werner! Seems like an important step!
Nov 13 2020
Nov 9 2020
Oct 26 2020
Oct 23 2020
Oct 9 2020
Oct 7 2020
Thanks for the quick analysis.
Oct 6 2020
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)
Sep 17 2020
Last report more than two years ago.
Sep 9 2020
--locate-external-keys exists since 2.2.17 and ignores the local keys.
Sep 7 2020
Aug 24 2020
On the ml there was another request for this use case
Aug 21 2020
Read through it, thanks for the updated description!
Aug 19 2020
Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.
Aug 18 2020
just reading the issue in detail.
Just reading this issue in detail.
Jul 9 2020
Jul 6 2020
Jun 29 2020
@dkg while I agree with your aim of
Jun 25 2020
Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.
This issue, as well as T4766 has the challenge that there is a disagreement about the usefulness of the use case, as far as I can see.
Jun 15 2020
To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.
Jun 11 2020
Jun 8 2020
How do I know that you've noticed?
May 28 2020
May 8 2020
@aheinecke thanks for commenting.
May 5 2020
Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):
This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.
Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.