Last week:

• Office stuff
• Jabber and other admin tasks.
• A litte bit of coding.

Possible topics:

• Releases (in the following order)?
  • libgpg-error new release
    • I want to have a new release for gpgrt_poll and gpgrt-config
  • libgcrypt new release
    • Shall I merge X448 (and Curve448 support) before the release?
  • GnuPG 2.3 release
    • Possibly, support Curve448 encryption with newer libgcrypt

It is not just about being annoying but for security reasons. It would be too easy for other applications *think webbrowser or Acrobat) to take a screenshot and pop up a modified version of that screenshot with data entries to act as a MitM.

$ gpg-connect-agent --dirmngr 'getinfo version' /bye
D 2.2.17
OK

Can you check which dirmngr version you are running

gpg-connect-agent --dirmngr 'getinfo version' /bye

thanks for the dns explanation - IMHO, there should be added something about that in the wiki
When it does not work for you on http1 either, then I guess, it's really just some outdatedness of my gpg/dirmngr and this ticket can be closed.

It does not work either. Your problem is the use of a wildcard DNS for archlinux32.org:

The test above was with gpg master but I got the same result with current 2.2:

ok, I disabled it again. btw: why do we need openpgpkey.archlinux32.org in the cert? Is this standard or did I misconfigure something?

Thanks. Here is a dirmngr log:

I set archlinux32.org back to http2 - so you can see for yourself, how gpg fails to retrieve the key for buildmaster@archlinux32.org

I believe, it means, that it may fall back to http1.1 - the documentation is not clear to me on this.
A simple test however shows, that at least curl has no problems to use http1.1 or http1.0 with the http2 enabled nginx.

Does your ngix configuration mean that there is no fallback to standard http?

And it is merged into master.
Along with the support of multiple readers/token, the parts which assumes Windows 32-bit are fixed, too.

For argparse.c, it can be only stopped with nonnull attribute for the API, I suppose.

I take this so that libgpg-error can be released soon.

Last week:

• Tokyo and suffered from train problem.
• PC/SC
  • multiple card support: T4620: no support for multiple (yubikey) smartcards plugged in at the same time
  • Investigate SCardGetStatusChange/SCardCancel for blocking API
    • Conclusion: It is racy when used for multiple access for cards with a single context
• My own environment of Windows
  • Takes more than a day to move from 1803 to 1903
  • Configure use of USB
  • Now ready for tests as a guest OS under Debian host

This week:

• Test new PC/SC on Windows

Last week:

• Work on keyboxd

The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.

The message has not been encrypted to you. Ask the sender to encrypt to you.

How to fix "failed: no secret key

This is generally the better tracker to report Gpg4win / Kleopatra issues. The git systems are linked in a way that I can both automatically add a commit here and in the KDE tracker.
I just noticed the KDE report a bit quicker because there is less traffic, but I would have seen it here within the day.

In T2300#90092, @aheinecke wrote:

Ah nevermind. I think myself that this is nobug and current behavior is correct.

To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.

There is no need to use the new CTB format for a packet with tag 3. OpenPGP implementations need to support all packet header encodings. We do not plan to make this configurable.

I created a branch for this task: https://dev.gnupg.org/source/gnupg/repository/gniibe%252FT4620/

I could not reproduce such a failure either under any conditions.

Agreed.

yep, the implementation thinks that the default signing key is expired due to metadata contained in the public keyring. The secret key is available to the implementation. So the error mesage No secret key can cause confusion and/or panic if the user thinks they've actually lost their secret key.

In my debian buster pbuilder enviornment I got the following failure: