@werner That begs the question: why can't quick-add-key re-use the same code that quick-add-uid is using?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 14 2018
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.
Done for npth.
Jul 11 2018
I have logging to a socket always enabled. That may explain why I don't see that error on Unix.
There were two things here:
Jul 10 2018
Works for me now.
On another note. We might also want to reduce the clicks required when certifying a key. The "I have checked the fingerprint" checkbox is out of time. People will check it regardless and we can't force them to do it.