My idea here is to have a discussed reference how the GnuPG community thinks a signature might be counted. Taking the discussions from our AutomatedEncryption stuff into account etc.
I would then like to extend gpg-error with the according strings / status codes.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 17 2018
Hi Mirko,
This was a misunderstanding. Import is possible. The german translation of Kleopatra wrongly indicated an error because it translated "unknown certificates" as "ungültige Zertifikate".
Jul 16 2018
Nothing special at all. Using sysvinit, not systemd.
Ran gpg and gpa as a regular user a few times. Then, after logging out, I found those processes still running.
There should be only one instance of gpg-agent running per GNUPGHOME directory (i.e per user). Is this a systemd system where you started gpg-agent in supervised mode (e.g. Debian) or a regular system. What is special in your setup?
Jul 15 2018
Jul 14 2018
@werner That begs the question: why can't quick-add-key re-use the same code that quick-add-uid is using?
if that is the case config.{guess,sub} needs to support this and we should be able to handle this the same way as other Unix platforms.
Right, but requires extra code. The --quick commands try to reuse existing code and, iirc, that is the reason why a user id is accepted for --quick-add-uid.
We do have a history of extending the API, no?
Jul 13 2018
You seem to have reached the wrong page when searching for msys2
I should have :) Thing is - a fix could be made in a backwards compatible way. So I don't really see your point.
The command line is an API and we will never break an API without a very good reason. If you didn't like that API you should have noted that on the devel mailing list years ago ;-)
And FWIW: an inconsistent UI/CLI should be treated as bug - not as a feature request.
You completely ignore the fact that --quick-add-uid and --quick-add-key are not consistent.
It's not clear why one should require a fingerprint and the other allows the kind of "user-id" you just described.
That was the main point of this issue.
The term “user-id” is used throughout gpg to mean some kind of user id beit is a name, a key id, a fingerprint, a keygrip, etc. See the section "How to specify a user id" in the man page. FPR is used if a fingerprint is required.
From the man page:
--quick-add-uid user-id new-user-id --quick-add-key fpr [algo [usage [expire]]]
I am not sure wheat I understand your request. --quick-add-uid takes a fingerprint as first argument you _may _ use a a user-id instead but that is for consistency with all gpg commands. Using the fingerprint is always highly suggested.
To clarify: I would like to see the targeting of keys be unified.
I see the following options:
Jul 12 2018
About how the keys are actually stored on disk:
The matching error message and the similar keywords let me to miss that - indeed.
You are mixing gpgsm and gpg - they have different semantics: That github mirror under the top name of "gpg" might
be a reason for that confusion.
it is not due to windows but due to the use of NTBTLS. I have the same problem here... and found it: We call es_fflush to let ntbtls flush its internal buffers but libgpg-error's estream module does no propagate this explicit flush to the cookie functions of ntbtls. Thus ntbtls gets stuck most of the time. I am not sure when this regression happened but it is pretty obvious.