CryptGenRandom is only used as an additional source of entropy and doesn't count towards our entropy estimation. Thus whether it is used of not does not make any difference. Our main entropy source is meanwhile the jitter based RNG. Thus your request will receive a low priority.

The problem with mnemonics based on words is that they are language dependent and only a small part of the world is fluent enough in English to spell/use them correctly. Thus anything based on ICAO spelling (Alfa, Bravo,...) is a better choice than arbitrary words from one language. Even if that meas to write down a longer string. A CRC is of course very useful.

It would be great if this feature were implemented with a mnemonic code option, with a built in checksum, as described in bip39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Using the same bip39 standard (and perhaps others, as alluded to in T3497) would also improve compatibility with existing crypto key storage devices (i.e. cryptocurrency wallets used as smart cards).

@werner That begs the question: why can't quick-add-key re-use the same code that quick-add-uid is using?

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?

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.

About how the keys are actually stored on disk:

To be released with 2.2.9

Agreed, after the verification succeeds the caller can (and probably will) check the signature notations.

re: last question: Marking a notation as recognized does not mean gpg does do anything with it or that it demands this notation. The latter can be handled by the caller. For example, gpg knows about "preferred-email-encoding@pgp.com" but does not apply any semantic to it.

Sorry, I meant the key pair (thought bundle) of private and public key.

Though a CFFI/ABI solution may be the only option, it would still be preferable to get SWIG working under Windows. The reasons for this are many, but not least of which would include not needing to duplicate effort to accommodate Windows, no functionality mismatch due to using the Windows version and not needing to implement every function manually since CFFI can't generate low level bindings the same way that SWIG does.

changing to testing is our marker for "done in code but not fully tested / released". It helps to keep an overview of the issues which are "done" for the next release.

Hi Andre,

This is implemented now and can be turned of in the new config dialog.

Backport done. To be released with 2.2.9.

I am not sure what you mean by “keybundle”. Is is a single keyblock or a selection of multiple keyblocks?

Done for master. Needs backport.

I manually configure IPv6 only environment, and now (forthcoming 2.2.9), it works fine for me.
So, I move this state to Testing.

As written in T2438:

I think that this is same issue of T2438: dirmngr fails repeatedly with "invalid argument", without kicking the host from its list.
Merging.

My bad this already exists.

On 06/17/2018 02:10 AM, BenM (Ben McGinnes) wrote:

The two subsequent commits are the one I mentioned above (nested try/except
statements) and followed by a major PEP8 compliance overhaul of core.py.

Thanks for the patch and welcome to the weird and wonderful world of FOSS. :)

This is still true even after the latest changes to GpgOL not to require Kleopatra or GPA through the UIServer protocol. The details dialog / search still uses Kleopatra or GPA as a fallback.

Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960

Not to worry, we've all been pretty busy of late.

test after system upgrades

Thanks. Pushed to master. I think it should also go into 2.2.

I've just pushed e037657edaf0b3ee9d2e30f6fe3edf6879976472 on the fix-T4019 branch

I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.

Apologies for the delay, been working on GSoC stuff.
Here's what I've got as of right now:

Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.

That makes sense. If you don't have any other patches floating around for this, would you mind if I took a crack at rewriting export?

Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.

Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).

Yes, this is actually pretty high on the wishlist but AFAIK there was not yet a task for this.

@gouttegd Thank you very much!

Following in-person discussion with @werner last week, I have now added this EFL pinentry to the master branch of pinentry (commit 948105b).

@werner, what protocol design rule do you think is not being followed specifically?

From the autocrypt page:

Let me state it again: Using symmetric encryption for authentication is Bad Thing™.

Please discuss this at gnupg-devel. A bug tracker is not a useful here.

@werner I was hoping to make a modified gpg-agent build that would let me walk through what's going on after the nonce is sent but it looks like the gpg4win process only takes in a package of pre-built gpg binaries which rules that out. As far as I can figure out, after the nonce is read and accepted, libassuan creates a stream object out of the socket and then finding nothing in the stream terminates the ssh handler. We send the actual client request immediately after the nonce but in a separate call to send() so I now wonder if by not having anything read in at the same time as the nonce gpg-agent or libassuan thinks that it's a 0-length stream.

Yes, this is on purpose, we display only the most important commands, similar to --help

A smartcard may do several dozen operations per second and thus spawning a tool each time is not the best option. A generic notification scheme would be better. OTOH, notifications about secret key operations may accidentally create an oracle - which is not good.

cross-sign is also missing.

Great! I did not notice this feature!
Is it on purpose that this is not shown by hitting TAB in the --edit-key command prompt (and auto-completion)?

The fingerprint is required because that is the unique identifier for a key. Without that we would need to presetn a menu to select between keys. This would make scripting complicated again. On the command line c+p is easy enough to hget the fingerprint. c+P is also the reason why we print the fingerprint by default without spaces.

You are lucky. This has been possible for quite some time and since 2.2.6 it is an official part of the API. See T3816

Ok, so I guess that you can close this ticket.

By standard I mean "behaves" somewhat like coreutils. Filename encoding,.. meh I see that this could be a problem.

Clearly getting SWIG and Windows to play together nicely is a bit of a big ask, but it may be possible to leverage GPGME's compiled libraries with something like CFFI's ABI calling method (yeah, I know, ABI is never ideal, but it's better than what Windows has now).

You need to give the --with-foo options for each package.

No, we won't cripple GnuPG for testing purposes. You intended to test something else than the provided GnuPG.

SYSROOT support is not yet fully implemented. You need to give the --with-foo options for each package.
I will retitle this bug to indicates tha tit is a feature request.