@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.

Thanks. I added you to the wiki page.

I think with the SRV entry, I can configure the server in the way I want to....

In T3437#104021, @werner wrote:

dirmngr has its own stub resolver to do DNS resolution via TCP so that it can be routed via Tor (to 8.8.8.8 which is a heavy traffic resolver and thus it will be hard to single out requests to other often used addresses.).

thanks for the links to documents.
we've setup submisson-address and policy links.

I see that the completion script already uses --dump-options :-)

dirmngr has its own stub resolver to do DNS resolution via TCP so that it can be routed via Tor (to 8.8.8.8 which is a heavy traffic resolver and thus it will be hard to single out requests to other often used addresses.).

okay, I see. Than I havn't found the documentation for this feature. This is enough for defining a different sever.

The only requirement here is that you use a subdomain of gnupg.org (here wkd, but any will work). This was added for those providers who have outsourced the top level domain but can still add new DNS entries.

Using a different server is actually supported:

I know, that I can't handle all WKD request under one domain for multiple once. But i could make sure, that autoconfig.<domain> would result under another IP adresse so I can handle all of the WKD request at another server. Add a own VirtualHost entry etc.

FWIW, I plan to add a few features to gpg-wks-server to make the setup of a new domain and installation of keys easier.

That does not work because a property of WKD is that the key you retrieve has only the requested mail address and no other mail address. Merging them all into one file, which you need to do with your proposal, removes that property.

Because of policy requirements I have.

The import-show thing is new. What you see is different from the default action of gpg when it encounters a keyblock. In fact, that old output was never well defined and basically a debugging aid.

Is this not a regression, rather than a new feature request? Earlier versions of GnuPG report sec rather than pub for such keys. The file itself is a private key - that it contains a public part is surely secondary in this context.

I agree that it is better to keep it in two directories.
(The potential advantages outweight the drawbacks.)

I see.

With the GPG4Win 3.0 Release, the software is differently distributed to the System. In the 2.x releases it was one folder (usually C:\Programms\gpg4win), now it is distributed to two different folder (C:\Programms\gpg4win and C:\Programms\gnupg). So the complete GnuPG files have been rearranged to their complete own folder.

Sorry, I don't understand this. Can you please elaborate?

For context, here's what the wisdom of the crowd is rigging together around GPG to get this single-sign-on feature:

For workaround (master branch with rG0a7661129499), moving the private key file to *.key.bak can do that.

Good idea.

Fixed in master, applying D297: 785_sign-fix.patch.
If needed, it will be in stable 2.2 branch, in future.

What is the benefit of two subkeys?

Thanks, that is interesting info, I need to look into that.

I spoke with the author of onionbalance, and they said:

I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.

You need to raise this with the IETF OpenPGP WG. First we need it in the OpenPGP standard, then we can implement Something (tm).

It is on the same machine, as I mentioned manually deleting ~/.gnupg/private-keys-v1.d/* is a workaround I have to use, but it is not very user friendly.

Sorry previosly I asked for more slots for keys on token. But its not
needed one. I dont even know it is a valid request but