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.

All changes in gniibe/t7855 are pushed into master.

Fixed in master: rGae431b04370f: w32:common: Take care of possible race on startup under Windows.

This issue should be fixed in 2.6, too.

Pushed the change to gnupg master: rG61ff3759e827: common,dirmngr:w32: Fix for semi-hosted environment.

In libgpg-error, I pushed thread-safe version : rE0313b660f8bd: w32: Don't convert slash->backslash when it's under Wine.
I'm going to push similar code to gnupg master.

Lastly, pushed a change into gniibe/t7855 branch.
rGf861b2a33f96: gpg,gpgsm: Fix thinko for FP closing under no lock.

I pushed further changes into gniibe/t7855 branch.
rG2fe62809014e: gpg,gpgsm: Serialize write access to keybox/keyring to protect.

I'm fixing this issue under T7855. So, I move this ticket as a child of T7855.

For remaining changes in 2.2, I pushed changes into gniibe/t7855 branch.
rGbd65b06b74c2: gpg,gpgsm: Don't lock recursively when KEEP_LOCK is enabled.
rG423fd047da87: kbx,gpg,gpgsm: Add FP-close method for keydb to close before unlock.
rG966258ac5f99: gpgsm: Fix delete and store certificate locking glitches.

I pushed changes into gniibe/t7855 for compressing the keybox.
rG8cc2a0e0ffee: gpg: Minor clean up for keydb_lock API.
rGe4d3c3aa2220: kbx,gpg,gpgsm: Introduce keybox_compress_when_no_other_users.
rG3e441d5b299f: kbx,gpg,gpgsm: More changes for compressing the keybox.