Thank you for applying the provided changes!

Applied and pushed.

@werner No problem. Just go ahead.

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|

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

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

Thank you.

Thank you. Applied and pushed.

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.

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

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

still actual problem (Gpg4win-3.1.15, Windows 10)

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.

Thank you.
Applied both to STABLE-BRANCH-2-2 and master (changing new function name).

CC_FOR_BUILD is used for building executables for the build machine.
CC_FOR_BUILD may be different to CC (for target).

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

Yes, will be fixed but it has no severity because the fault is actually by the caller.

Referencing external patches is not sufficient

What is vcpkg?

Sorry, I can't parse your message. Please describe the problem or feature requests. Referencing external patches is not sufficient. What is vcpkg?

Thanks. I understand that this is no big issue in the test code, but half of the code paths have proper cleaning already so fixing it once should save anyone in the future going through the same issues over and over again during our releases or anyone else who would run your code through static analyzer.

Thank you.
For get_attr_l, I pushed a fix as rE89a353f418f5: build: Fix gpgrt-config for handling 'Requires' field.

Actually I don't care about releasing resources for regression test failures.
The other missing free is for code which is commented out (#if 0) but should eventually be fixed.

Note that rndjent.c is already build with -O0 as can be seen in example above. That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

FYI, I sent DCO to gnupg-devel@gnupg.org some moments ago, so I hope it arrived correctly.

This feature does not use Outlook per se.. It's a problem with Exchange really. An Exchange Add-in would be needed to solve it, an Outlook add-in such as Gpgol can't do anything about it..

Seems that it is not a coincidence that Wayland starts with a W like Windows. ;-)

Fixed in 1.42.

You are coming pretty late to the party ;-). Since 2.1.0 we don't use the ancient keyserver helpers anymore but reworked the entire network access. I even doubt that I can still test with a 2.0 version.

We have two or three other open issue which I would like to address before a release. FWIW, release ticket is T5305.

Do what ever you want with _gcry prefixed functions - this is never considered an API or ABI break. There are some exceptions for internal functions used by macros but those are clearly marked.

Good to hear that it works now.

I already backported the above for Fedora so I am not in hurry now. But I believe others might hit the same issue.

@werner Can you comment about bugfix release?

These functions are internal to library and, for example, on linux/windows builds are not externally available.

Admin here. I'm sorry your replies did not make it to this site but somewhere got stuck. So copying them for completeness:

Very strange. Both logs show no error.

Sorry, first log was without API.
This log includes API calls.

Here we go. ;-)

Just drag and drop it into the input field. There is also a little cloud icon that makes this explicit.

Thanks for this very quick reply.

Mmh, all these issues should be fixed with the most recent versions.

The optimization introduced for curve 25519 and curve 448 en-bugged for usage of direct MPI.

Yet another identify theft scam committed by clang.

This patch should work if configure properly detects need for extra underscore on C symbols:

This patch should work if configure properly detects need for extra underscore on C symbols:

Please look at the code:

Sorry to dig up an old report...

Sorry to dig up an old thread...

Here's the patch I am using for the Apple M1: libgcrypt-darwin.patch. The patch is public domain so anyone is free to use it.

This is kind of a hack, but this patch: