Okay, can you please provide sample data for the test suite? Best using one of the existing keys but adding another one won't harm either.

DKGPG will contain programs to generate such signatures in its next release. Thus it would be nice, if those signatures can be verified by GnuPG as one of the most widespread OpenPGP implementations.

What are your use cases?

I don't think that GnuPG >= 2 can still be build with RISCOS. In any case it is such a minor platform that we are removing special RISCOS hacks when touching such code parts.

Apple Clang changes the -fno-common to be default. It can also compile by adding -fcommon to the CFLAGS but I suspect this patch (with the exception of adding __APPLE__ to the (defined (__riscos__) || defined (__APPLE__))) would be needed for things to work properly on __riscos__ also.

-fcommon, -fno-common
       This flag specifies that variables without initializers get common linkage.  It can be disabled with -fno-common.

Do you say that the linker can't handle the standard common block feature? The only toolchain I am aware of which does not understand this is the Norcraft C compiler for RISC OS. And now also Clang building for iOS?

With certified keys the automation is working as expected.

Well, I have already tried to explain the use case: To make using cryptography easier for our users (for most of them the command line is the hell ...) I have integrated GnuPG in our webmailer. The webmailer has a key management page where you can import and export keys (up- and download, import from mail, attach to mail etc.), where you can edit trust settings, and where you can sign other keys and revoke such signatures. The webmailer certainly does not offer all capabilities of GnuPG but certainly a substantial subset.

The option you mean is "Disable non-blocking encrypt / sign", correct?
It's english in the german dialogue, btw.

This seems very special and I'm not sure if we should not say at some point that we won't add quick commands for everything ;-)

The crash on send should be avoidable by checking "Disable async encryption" in the options.
Yesterday I got a new OL 2013 test system with which I can reproduce the crash. So that will be fixed or worked around for the next release.

no. Outlook 2013 reproducably crashes on sending and won't toggle
encryption on.

Sure, this should work, local keys are preferred.

But can't I simply use the keys in my local keyring?

No you can not use an "external" Web Key Directory. The point is that the provider (your domain) should be the source of the keys as it already manages the mail account. ( For more info see: https://wiki.gnupg.org/WKD )

I downloaded GPGwin v3.1.3 beta 20 today. The automatic key fetching fails in my case because we have no WKS. Never heard of that before.

Windows 10 was obtained last week and the process of preparing a Windows build env began earlier today.

Good to know, no problem, just wanted to document it just in case they do remove the API entirely in the future.

Indeed. Thanks for the reminder.
There is some code currently in there already but its not yet fully implemented. Needs to be finished.

Deleting a user id is more or less useless. What you want is to revoke a user id.

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?