@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.

If we need to backport the locking fixes to 2.2, these two will be the start of changes:

Scute fixed in rSc3dc9c581631: w32: Use CSIDL_COMMON_APPDATA if available.

Here is my proposal:

Here is my analysis.

The extension .part is used by Mozilla/Firefox. Curl uses .tmp. Is that OK for Windows machine to use .part?

I examined the code of gnupg_sysconfdir in gnupg/common/homedir.c, if we could factor out things to gpgrt, so that something like gpgrt_fconcat with GPGRT_SYSCONFDIR can be implemented.

When --output option is used and the user uses temporary file and is ready for checking an error, that is, it's already prepared, it's redundant and useless, indeed.

Let me explain about the change rG57affc4e98ab.

Applied the change to master: rG57affc4e98ab: common,agent,dirmngr,kbx:w32: Synchronous spawning daemon process.

I applied a change with GPGRT_ATTR_NONSTRING to master, since 2.6 branch now requires newere gpgrt.
Fix is rGcad79e542d85: agent,common,dirmngr,tests: Silence warnings of a compiler.

Applied the change to master: rG57affc4e98ab: common,agent,dirmngr,kbx:w32: Synchronous spawning daemon process.

At line 133 shouldn't we have used iobuf_cancel there?

I believe this bug was fixed by T7829. Please confirm with new gpgwin-5.0.0-beta.

@ikloecker says that Kleo already support this feature. (I didn't know that.)
So, compatibility flag to switch on/off the feature would be needed,
or this feature is not needed in GnuPG at all.

Here is my attempt to do that:

I checked the code under gnupg/dirmngr. Those are no harm.

That's my mistake with KEM API.

Here is my idea to implement the feature:
(1) Extend struct iobuf_struct to have a field of temporary output (of int), just after real_fname.

• OUTPUTFILE: When it's 1, it means that a temporary output file generated with real_fname original suffix removed and appended .tmp

(2) Modify get_output_file in plaintext.c and make_outfile_name in openfile.c, so that OUTPUTFILE semantics above is used and the field in iobuf_struct is marked accordingly.
(3) Modify proc_encrypted in mainproc.c so that it can rename .tmp file to the OUTPUTFILE or it can remove it when failure, when the field is active.

Applied to 1.11 branch.

Let me explain the background.

For gpgrt/argparse this could be an option (to remove hard-coded /etc):

Added a compatibility flag in: rGad0c6c33c3d6: gpg: Do not use a default when asking for another output filename.

Fixed in rG115d138ba599: gpg: Fix possible memory corruption in the armor parser.

Fixed in rGdb9705ef594d: gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures.

Pushed the revised change to master.

Fixed in 2.5.13.

@onickolay The change was originally introduced for PQC stuff. And then, we applied use of KEM API (of libgcrypt) also for ordinary ECDH, so, it affected ordinary ECDH encryption (between 2.5.9 and 2.5.12).
The intention is follow the recommendation of use of KEM. IIUC, next FIPS certification will require use of KEM, possibly.

Thank you for your report.

Note that:
If we consider backporting this to 1.10/1.11 branch, we also need to apply: rCdef1d4ea8f66: random:jent: Fix build with address sanitizer.

@jukivili
Thanks for your feedback.

For the initial attempt, I push: rCfe06287003a1: secmem: Handle HAVE_BROKEN_MLOCK for the case with ASAN.
This is better than nothing.

Still, there is a fundamental problem with keydb locking.

• It only assures no-data-corruption.
• When a process doing write access, another process reading the resource may encounter a problem (inconsistent data read), since data could be changed while accessing.
  • Currently, write access may occur with keybox compress, this means that users are not safe to invoke multiple gpg/gpgsm simultaneously (to be sure).
    • It would be: only keybox compress when users explicitly ask.
  • We could introduce a lock to read access... BUT naively adding a lock (both for read and write or read-multiple-write-one) results possible deadlock in gpgsm
    • in gpgsm, gpgsm_walk_cert_chain and gpgsm_validate_chain access the resource of keydb in a way of:
      • While it has a handle kh, by find_up routine, it may call keydb_store_cert by callback routine; The callback does write access to the resource opening another handle.
      • Currently, it works because of no lock for read access and keydb_store_cert appends data at the end.

All changes in gniibe/t7855 are pushed into master.