Ok.
But`CFLAGS_FOR_BUILD` not mentioned in build rule for mkheader

In T5217#144071, @ikloecker wrote:

Except for T5341: gpgconf does not list default_pubkey_algo pseudo option anymore, this should be done.

Applying changes is fixed.

Reopening because at least a debug build of Kleopatra crashes with an assertion when applying changes.

Yes I agree it makes sense to have this as an explicit setting to cover both use cases.

This really depends on the use case. Some people want to extend the lifetime of their whole key. Others explicitly use a long-lived primary key with short lived subkeys. A possible heuristic for the default behavior to propose to the user would be to check whether the current expiry dates of primary key and subkeys are the same or not. The user could still change this proposed default in the dialog that's anyway shown for the new expiry date.

Yes the other one was a duplicate, somehow my search didnt find this and I thought I had forgotten to open the issue.

Done in 2.3.0.

Done in 2.3.0.

Done in 2.3.

Thank you.

Thank you. Applied and pushed.

I'm sorry I disappeared on this issue for two weeks; I just got reminded of it by seeing the e-mail with the status change. I've updated to the latest gcrypt (which is the commit with the patch, now pushed to the repository) and was able to upload this to Apple without it being flagged; thanks!

Thank you. I'll take care of this.

Regarding your patch, I am personally not opposed to it, but apparently Debian’s policy says the library/module should be called scute while Gentoo’s policy says it should be called libscute… What should an upstream developer do?

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

The built file is called scute instead of libscute because it is considered to be a *module*, not a *library*. That’s apparently a Debian thing, see commit dc2211179ea7f63434d726eefbc425390c4c6427.

Isn't this a duplicate of T5336: Kleopatra: Add expiry for certifications in certify dialog?

(FYI I did not notice any other errors with 2.3 so far)

This is a patch that fixes the build, I am not sure why -module is not used when HAVE_DARWIN_SYSTEM is defined, but I preserved that behavior. If its not intentional it could be added directly to libscute_la_LDFLAGS instead.

No Apache - No Default charset per suffix. The version for browsers is the HTML version.

This was changed in kleopatra some time ago to also generate keys with 2y expiry. So the motivation for this issue is gone.

Hi Ingo, If you run out of work you can do this next. Its already something that I'm showing during product presentations and a workflow I would like to recommend.

I noticed when testing the surprising behavior that when I changed the expiry on the primary key (tested with a smartcard) it did not change the explriy on the subkey. I think in the past it must have been different that the subkey did not get the expiry by default.

Thanks I talked to werner and agree that this is something to work on next. As we are pushing for more LDAP servers used internally which will use the common search and not the WKD discovery mechanisms.

Do we have CVE number assigned?

Thank you for your publishing your key of CB6BE1D0D7D1594A.
I applied and pushed your changes.

The surprising thing is that it works at all. I wouldn't be surprised if certain would simply reject it as "not a pdf" given that the "%PDF-1.x" marker isn't at the beginning.

It may be preferable to get that under 4.0 or later, so you don't need to contact every contributor again if in some years there is intention to switch to a newer version released by Creative Commons.

still actual problem (Gpg4win-3.1.15, Windows 10)

This would be difficult to set up for DSA. Remotely controlled
environment, asking signing same message, using deterministic
DSA... would be not that practical.

Thanks. Note, that the same code is in gnupg2 in common/exechelp-posix.c:736

In T5381#144927, @gniibe wrote:

For gpgrt_wait_processes, I modified it to skip invalid PID.
The change is: rE956c40f106ea: core: Fix gpgrt_wait_processes, by skipping invalid PID.