The manual states that --standard-resolver is mostly for debugging. The reason you get an "not enabled" is that we can't allow direct DNS queries in Tor mode which would happen with the system (standard) DNS resolver.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 25 2019
Nov 23 2019
In T4726#130765, @werner wrote:Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example).
[...]
To answer your question: With the exception of case two this is desired behaviour also in the future,
Nov 22 2019
Please no bug reports for the development branch. You need to have a recent libgpg-error. We do not update the requirements checked by configure for master immediately. It is better to report this to gnupg-devel if you are sure that you have the latest versions of all libraries.
Nov 21 2019
Nov 20 2019
Nov 18 2019
This will be in 2.2.18, closing.
In my own opinion, it will be good when desktop environments support GnuPG as one of first class citizens, to protect user's data.
For example, currently, libscret stores secret data (such as WiFi shared secret, etc.) by its own cipher preference and method (and it is symmetric cipher by user's password). I don't think it is secure enough.
For me, it will be good if it is protected by user's gpg key using asymmetric crypto.
Nov 16 2019
UserIDs are mandatory and do not see any reason to change this except maybe by specialized application in the embedded field.
Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example). The risk of a regression in that case is pretty low.
Nov 15 2019
it is just that we won't fix that for gpg 1.4.
Wow thanks for the great explanation! I've always wondered what is the relationship between gnupg and other secrets services. Personally, although Gnome's / KDE's secrets services offer better UX out of the box, I've always preferred gpg's agent because I can control it better from the command line and hence customize it's behavior. The only use I have for gnome-secrets service is for a few passwords I always want them to be cached (because I obtain them in systemd timers+services). Do you think Gnome / KDE will ever plan to _use_ gpg-agent, instead of reimplementing it?
Sorry in advance for long explanation. :-) Well, let me show my stand point at first (to avoid confusion): I don't like the concept of "desktop integration" when it makes difficult for a user to control his environment.
Nov 14 2019
Works! I still wonder though: How come my system / gpg agent has all of a sudden started using the external cache? Is this a new feature of gpg-agent? And what is the meaning of this message:
Could you try to put no-allow-external-cache in your gpg-agent.conf?
If it changes the behavior, it is your desktop environment which caches your input, I suppose.
I thought I close this after the release of 2.2.18.
Anway, it's done, so, closing.
Nov 13 2019
Nov 12 2019
We use "error ..." and "failed to ..." interchangable. The German translation even uses the same term for both.
Thus I think it would be better to keep the old diagnostic but show it only in --verbose mode.
I did not want to move the fingerprint verification process more prominent with an entry field or something like that.
With the new version we get an even more extensive rework of the certify dialog. We now also have support for search tags.
It's probably a wrong encoding in the italian translation. Will be fixed with updating our build system to buster and NSIS-3
Is this resolved?
I tuned down the error message. I don't think there is a problem here anymore.
Nov 11 2019
See also D475.
Nov 9 2019
BTW, since I start my X session with startx, these are the relevant parts I have in my .xinitrc:
So my gpg-agent.conf file looks like this now:
Please add
Nov 8 2019
Nov 7 2019
In T4726#130609, @werner wrote:-r STRINGdoes a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup.
does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.
DETAILS says:
*** PLAINTEXT_LENGTH <length> This indicates the length of the plaintext that is about to be written. Note that if the plaintext packet has partial length encoding it is not possible to know the length ahead of time. In that case, this status tag does not appear.
Sorry, we can't replicate this with the current pinentry version.
I always select both files and click to verify, I thought that was the way
it was supposed to be done, that I should provide the file and the
signature to the program.
Just downloaded the file and signature and there is only one signature. Just verifying the signature also does not result in duplicated results.
"PLAINTEXT 75 ..." means UTF-8 encoding (u) which is not not binary (b) or MIME ('m') and thus on Unix the line endings are converted from CR,LF to LF. On Windows you should see a different length. See plaintext.c#handle_plaintext()
Thanks for the report. I'm only giving it low priority because while it is ugly it is no loss of functionality.
Nov 5 2019
Nov 4 2019
Thanks for the report. I fixed this for the next 2.2 release and put a not in the source file to not translate the keyword.
Nov 1 2019
Oct 29 2019
Thanks for the follow-up Werner.
Dehydrated problem after the last server update: https://github.com/FlorentCoppint/dehydrated/commit/aed6f4ba06858c926042b95f1cef4a7a681ddf88
Then better do not use a curses pinentry. It can't guarantee that another process changes the tty properties. For security reasons it is better to run the pinentry in a different window (ie. a GUI based pinentry).
Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.
Oct 28 2019
Please test. When I can confirm that it is stable, I'll backport it to 2.2.
Oct 25 2019
Please no reports for non-released devel versions.
Ping.
Oct 24 2019
@werner, are you saying that gpgme is not fully supported for use with gpg 1.4?
@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?
Oct 23 2019
In T4726#130341, @werner wrote:This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.
This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.
That seems to be gpg 1.4 which we do not fully support.
Is this task maybe related to T1927?
Thank you @dkg for creating the bug report! I would like to glean the following information from the above mentioned discussion.
@justus can you provide an example of the gpgme code you're using that generates this weirdness?
Oct 22 2019
Oct 18 2019
Still unresolved...
Oct 17 2019
GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.
Oct 15 2019
@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC
@pow, thanks for a reference. But problem here is that there are multiple products with same name.
Oct 11 2019
I've also noticed this issue on windows when trying to symlink %APPDATA%\gnupg to $HOME/.gnupg under msys32.