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.

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

t-stringhelp change was pushed by rG8a95e963d53a: common: Fix the test of t-stringhelp.
For int-truncation, I pushed the change rGbcd87ea2b2da: misc: Validate the value on the use of strtol.

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.

For someone who considers the rejection is the requirement of the spec., here is a change:

Here is a revised patch (hopefully the last one):

We can use:

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

Here is a patch (revised since the email of mine):

For t-stringhelp.c, here is a fix.

For

openpgp_oid_from_str has a wrong memory-safety assumption

For Integer Overflow in literals_seen, I think that the claim is wrong.
When literals_seen becomes two, GnuPG stops processing to return an error.
It's not possible for GnuPG to keep processing.

For Integer Truncation of Arguments report, since the int value is limited to one-octet value, we could add check for the length of input when we use strtol.

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.

Fixed in rG8abc320f2a75: gpg: Error out on unverified output for non-detached signatures.

This feature should be only enabled with a compatibility flag.

Mitigation would be: adding context validation in add_onepass_sig function, which checks WHAT of armored input.

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.