Okay, maybe this should just be added to the 2.2.x docs.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 18 2019
Thanks for your comments. It would have been cool if this restriction would have been noted
in the gpg options documentation. (Where is was missing at least where I was looking.)
You may want to use a recent version of GnuPG ;-)
Here is my understanding:
--log-file option is valid for for background task like gpg-agent, dirmngr and scdaemon.
For gpg, it only works with --batch or --server.
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.
it's been almost a quarter year since my last nudge on this supplied patch. It's not clear to me why it hasn't been merged in master. I'm trying to not be a nag, but:
Nov 17 2019
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:
This is a bug tracker and not a general help line. You are better off asking on the gnupg-uisers mailing list.
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.
This should be normal priority as we continue to receive bug reports about UIServer and the usage in GpgEX of the UIServer protocol keeps us from removing it in Kleopatra.
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
I removed it. Looks dead to me.
Is this resolved?
I tuned down the error message. I don't think there is a problem here anymore.
To clarify this for someone other then me:
Nov 11 2019
See also D475.
Nov 10 2019
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:
auto key retrieve using just the key id is dangerous because it can lead to a DoS. It is too easy to flood keyservers with several keys have the same keyid. Let's don't give an incentive to the script kiddies trying to pull down the OpenPGP keyservers.
Please add
Adding werner to reviewers since this references his commit.
Nov 8 2019
El vie., 8 nov. 2019 8:19, johnmar (John Martinez) <noreply@dev.gnupg.org>
escribió:
Allow me to clarify. For bounty purposes, as long as the intrinsic implementation matches or beats OpenSSL performance, it is acceptable. There have been cases where the use of certain intrinsics may yield better performing, but sub optimal results.
Sorry, I don't know which source code comment you are referring to. You mention the comment at https://dev.gnupg.org/T4628#128529 as well, but neither this commit nor be99eec2b105eb5f8e3759147ae351dcc40560ad contain such comment.
Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.
As I already stated: Please read the source comments on why we do this
C-based intrinsic implementations are discouraged.