The default validity period can be specified in the configuration file with

[CertificateCreationWizard]
ValidityPeriodInDays=42

Quick gen key is only used for the keygen in GpgOL and KMail. Kleopatra itself uses the old batch generate interface.

--quick-gen-key supports this but there is no general option; the 2 years are hard coded.

This works with the message class changing. We still need to do it for OpenPGP, too.

This has been resolved with rOb05416e7bc41

And I also did a backport to 2.2 :-) See rGa028f24136a062f55408a5fec84c6d31201b2143

There are likely some bugs in the new code and I also want to do some improvements; see rGb4f1159a5bd7. But things should basically work as before and thus I set this again to testing

i'd be unlikely to ship anything as /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf just because of the mess that admins have to deal with when shipped config files change.

Arggh, gpgconf uses its own option parser so adding the global config file there will require some extra work.

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

All done in master with the latest libgpg-error (see T4859). There is always a global configure file in /etc/gnupg (or whatever "gpgconf --list-dirs sysconfdir" prints). The name of the configure file is the same as the user config file (gpg.conf, gpgsm.conf, gpg-agent.conf, ...) but for gpg.conf no versioned config names are used.

Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.

This is fixed now.

This is fixed in Gpg4win-3.1.11

We now have a decent error message for this.

Maybe it is the same issue described in https://dev.gnupg.org/T4717 ?

I think we can fix it by removing the smime attachment from OOM, because we still have it in MAPI, we just never cared that it was also in OOM (where only our decrypted attachments belong) because it was hidden.

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.

We should publish a status report about the campaign. I'd suggest to do this a few days before the 2.2 release.

All of the campaign videos have now been published.

My understanding is that the "donate to gnupg" at the end is meant for the "still" screen at the end of the video after the video stopped playing. There is another "donate to gnupg" message *before* the credits that is 8 seconds long.

Great that we have the video finished. Some minor corrections are required, though:

Meanwhile I added an explicit test mode to Payproc and implemented preview.gnupg.org to test the donation system in the close to real environment. The test mode allows to do payments in a sandbox without shoveling real money.

See {E164}.

@marcus brings two good LED flat pars, and asks the hackerspace to borrow the lavalier mic and radio transmitter/receiver. He also brings his zoom as backup.