Using an external process as an option is fine. However adding more dependencies to gnupg should be avoided.

So… Is there any interest in the approach I drafted in D442?

Okay, lets try with a default of 64. Note that for many concurrent ssh sessions you may also need the option --auto-expand-secmem which will come with Libgcrypt 1.8.2 and GnuPG 2.2.4

Debian has this with migrate-pubring-from-classic-gpg ( https://sources.debian.org/src/gnupg2/2.2.3-1/debian/migrate-pubring-from-classic-gpg/ )

Could we please merge it to the stable branch (2.2.3 does not have this patch yet) or it is not tested enough? Existing subkey sellection strategy doesn't play well with mail signing and affects GPGTools/GPGMail users as well as any other users with multiple signing subkeys. Thanks!

Moving on, I will just look to make a stand along project for efl-pinentry interface. I withdraw my previous submission. Welcome to resume and move forward with Mike Blumenkrantz version. Thanks!

Frankly, I doubt that this belongs into gpgme.

With Gpg4win 3.0 we registered associations for S/MIME and OpenPGP Files:

Not sure this should remain open. Months later a release was done excluding this. Originally mentioned on list in October 2016. Over a year later still not included. Very discouraging. I guess I can just see about having this external for myself. Shocking that FLTK and QTK see more usage than EFL which is part of Tizen OS. Clearly issues with either me, or EFL. Some reason it was excluded and being ignored. Seems nothing I can do either way. Oh well, I did all I could for months. On a very small contribution...

Kleopatra will only expose the values that are settable through gpgconf. Messing with preferred hash algorithms is nothing a user should do as the defaults are thought through and discussed. Mostly such changes come from bad recommendations. So the GUI / gpgconf does not offer this prominently as we don't want to create problems for users.

As GpgEX only queries a UI Server (GPA or Kleopatra) this is a Kleopatra or GPA problem.
With Gpg4win-3.0 Kleopatra got the option "Encrypt with password" in the file encryption dialog, which does symmetric encryption. GPA does not offer this but as Kleopatra is our main UI for GpgEX I think this feature request is done.

Somehow I expected such a report (too many open fds). We will need to replace our select based code by poll. However, I think this is more related to T3529.

THANK YOU! Once you push those changes, I'll see about back-porting the patches to Debian stable/Ubuntu LTS.

Thanks for your patches. I decided to do this similar but I need to take several branches in account.

The attached patches make the necessary changes to libgcrypt and gpg-agent. A word about my change to libgcrypt. Since all of the *_secure allocation operations were hardcoded to set xhint to zero, I simply replaced that hardcoded value with a static variable. In the patches I have some sample documentation for both changes. My scheme skills are quite old, so I did not write a test case.

Here is the test case that I wrote a while back (Follow-up to Crashes with gpg-agent 2.1.18). It is written with bash in mind and creates a stand-alone GNUPGHOME directory with a pinentry routine that supplies the password (I guess I could have preset the passphrase) and then starts 200 concurrent gpg decryption requests. With GPG 2.1.18 and up, this usually exposes the out of memory situation very fast.

To compute the key validity (trust) more information may be needed and we can only do that after the changes have been saved. Further, no-auto-chec-trustdb will anyway delay that computation until "gpg --check-trustdb" is run (e.g. by a cron job).

Not possible to replace it through config as we can't "check" like with sha1sum and the format differs.

In Kleopatra this should be possible through the Checksum definition config without any code changes. I'll look into it.

That is the same as a key generated from a passphrase. We have already have a task T169 for this. Thus I merge them.

This is intentional with the rationale being that users either want ascii armor for some reason for all their usecases or they don't want it.
And most users won't even know what ASCII Armor means (Adding "Armor" sounds like additional protection). So we moved this setting into configuration and renamed it.

So, to protect against this attack, the client needs to do both of the following:

Here are two examples:

@werner suggests using an ephemeral home directory. this is an important point.

@justus asked for examples.

@aa: From the mail address associated with @t62q7_aa I assume that this is an alias of your. If that is really the case please delete this alias and do not create another one. That would not be acceptable use.

if you're do not have an infinite time, at CERN we're about experimenting stuff at plank scale ...

do you have infinite time, just asking ...

This is not an issue of GnuPG. Sorry.

Please take discussions to the mailing list. A bug tracker is not a good place for it because only a few will see that.

Well, I gues it's complex enough to warrant strategic discussion, which can be done in this ticket :)

In the autocrypt spec, this is called a "setup code", not a "backup code" :)

This dialog actually belongs to Kleopatra. I added the respective tag.

How about adding support with private in keyparam?

• (genkey(rsa(nbit 2048)(d xxxx)(p xxxx)(q xxxx)(u xxxx))) ; Only p and q, is OK
• (genkey(ecc(curve cv25519)(flags djb-tweak comp)(d xxx)))

I would consider this feature request. Right now you can do this by providing an empty keyring.

Thanks for the information.
Closing, as I pushed rC94b84360ca55: Add OID information for SM3..

CESI also publishes a complete white pager documenting OID assignment in details. See http://www.cesi.cn/201612/1688.html and download the pdf. Search "10197" and I see the following info:

OK, I found: http://www.oidchina.cn/oid/release/1.2.156.10197.
站点： 国家OID注册中心
数字OID： 10197
中文OID：
英文OID： sca10197
应用范围： 密码标准化技术委员会

I use: 1.2.156.10197.1.401

I am now examining OID allocation.
I'll add the OID of SM3 into sm3.c.

GnuPG does not mess with suffixes but Kleopatra has some rules of it own which might be common to KDE. I thus flag your report as a feature request.

gpgme shall provide an interface for commonly required tasks but it shall not expose everything from gpg.

I guess it depends on whether you want gpgme to be an interface to OpenPGP certificates more generally (in which case, exposing the primary flag would be useful), or just a gpg frontend (in which case, the current behavior might be ok)

Okay, will be fixed in 2.2.2.. I actually found a bug while working on the patch.

It is likely that gpa will be changed to always use the default algorithm. Users who have special requirements will need to use gpg on the command line.

Right, but gpg has a strategy to figure out what it considers the primary (ie. the user id commonly printed). If we would merely convey the primary key flag to gpgme, gpgme or the gpgme calling application still needs to figure out what it considers the primary key - that might be different from what gpg shows.

In T3457#104401, @werner wrote:

gpg --print-mds  FILES
gpg --print-md ALGO FILES

But there can be several user IDs that are marked primary, right? I know that gpg tries to not let that happen, but there are other OpenPGP toolkits out there, and composite/hybridized keys, etc where this could happen.

In T3454#104310, @gniibe wrote:

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

In T3454#104309, @gniibe wrote:

Thank you. The diff doesn't include sm3.c. Could you please update?

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

Thank you. The diff doesn't include sm3.c. Could you please update?

This is the review request link: https://dev.gnupg.org/D449

Well, it is already there:

gpg always returns the primary user id first. (see gnupg/g10.keylist.org:reorder_keyblock). gpgme keeps this order and thus the first user +id in the linked list is the primary user id. If the primary user id flag is not set the first is the same what gpg considers the primary user id. I can add this to the documentation.