@werner No problem. Just go ahead.

In T5394#145082, @werner wrote:

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.

In T5393#145158, @werner wrote:

Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.

Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.

@gniibe: If you don't mind I would like to steal task this from you. I have noticed a few things which could get a little code refresh in addition to the fixes.

There is couple of issues that I did not want to propose a patch for, but might require some attention:

Error: IDENTICAL_BRANCHES (CWE-398): [#def28] [important]
gnupg-2.3.0/common/tlv-builder.c:353: identical_branches: The same code is executed regardless of whether "tag < 31" is true, because the 'then' and 'else' branches are identical. Should one of the branches be modified, or the entire 'if' statement replaced?
#  351|     (void)constructed;  /* Not used, but passed for uniformity of such calls.  */
#  352|   
#  353|->   if (tag < 0x1f)
#  354|       {
#  355|         buflen++;

There are also couple of reports about the function default_homedir(), which is supposed to return const char * but in reality, it sometimes allocates memory while callers do not expect it so they do not free:

Error: RESOURCE_LEAK (CWE-772): [#def11]
gnupg-2.2.27/common/homedir.c:477: alloc_fn: Storage is returned from allocation function "default_homedir".
gnupg-2.2.27/common/homedir.c:477: var_assign: Assigning: "newdir" = storage returned from "default_homedir()".
gnupg-2.2.27/common/homedir.c:488: noescape: Resource "newdir" is not freed or pointed-to in "make_absfilename".
gnupg-2.2.27/common/homedir.c:490: leaked_storage: Returning without freeing "newdir" leaks the storage that it points to.
#  488|     the_gnupg_homedir = make_absfilename (newdir, NULL);;
#  489|     xfree (tmp);
#  490|-> }
#  491|   
#  492|

The PKCS#15 support has meanwhile received a major update. Thus we need to test with the other cards again. If there is something special for to do for a certain task, a new subtask should be created.

Should be done

Thank you. The initial run was against olderer version of gnupg (and had one issue in g10/keyedit.c -- see the new patch with fixup). Now I ran it against the version 2.3 and there are couple of more issues to be fixed (rebased on top of already applied changes and the previous commits).

Done for 2.2. and 2.3.

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)