In T5395#145417, @gniibe wrote:

I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?

I applied 1,2,3, and 5 in rKfbb1f303198b: Fixes for static analysis reports.

I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?

IIUC, with libgcrypt in LIBGCRYPT-1.8-BRANCH (not yet released) and libgcrypt 1.9.3, the build process works well (the problem with SIP has been handled).

In T5401#145379, @werner wrote:

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority.

Yes, this is an edge case very unlikely to be encountered. The odd thing is the generated "ed25519" subkey does somehow encrypt and decrypt without issue.

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority. I would anyway suggest to use

Thanks, that was right in time for this weeks 2.3.1.

This has been fixed in version 2.2.16.

Fixed in rP7f7fd8bcfd74: tty: Fix error return paths and its resource leaks.

Actually, calling do_touch_file when some error(s) are not good.
Let me fix all the things.

Ok, thank you. I think task can be closed.

I hope last amendment is the following, which can happen if the tty can be opened only for reading but not for writing:

--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -583,7 +583,8 @@ tty_cmd_handler (pinentry_t pinentry)
   if (pinentry->ttyname)
     {
       fclose (ttyfi);
-      fclose (ttyfo);
+      if (ttyfo)
+        fclose (ttyfo);
     }

gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.

Thank you.
We also need to release memory for points.

Please tell us more details on how we can replicate your problem. Which Windows version, any non-standard software installed, non-standard installation direcories etc. You may also provide the output of

mkheader has CFLAGS_FOR_BUILD since libassuan 2.5.4.
gost-s-box has so since libgcrypt 1.9.0.

Done for gpa.
Please test.

Done for pinentry.

This task includes multiple issues: two sub-tasks and how-to-use remotely.
Two tasks had been fixed already.
The last one was documented here.
So, closing.

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.