gpg4win expired code signing cert; please renew.

[Jay Acuna]

On Sat, Oct 18, 2025 at 1:30 AM Robert J. Hansen via Gnupg-users
<gnupg-users at gnupg.org> wrote:
> > The why bother; is because it is best option available, for now.
> Your proposal has been heard, considered, and soundly rejected. Could we
> please return to discussing GnuPG?

I don't care if solely you, some random user on the internet reject it.
This is a good way to use gnupg.   This is what you have for a
solution to the problem in general.
What if I want to encrypt a file such that (USERID1), (USERID2), and (USERID3)
must all co-operate in order to read the file?  Multiple keys
necessary to unlock

gpg -e -r  USERID1 <  inputfile.txt  | gpg -e -r  USERID2  | gpg -e -r
 USERID3 > output_file.gpg
As far as I know there is no better way than that provided by GnuPG as
an option.


You speak as if you invented the crypto or whatever, and I ever came
for approval.
The point is I shared best practice to append post-quantum protections,
to your security plans, and it is fine if you disagree.

That it is now one best practice to add quantum protection, and chain it with
addition to existing procedure If the technology is not available to combine
that into a single function.  Given input -> A -> B -> output.  It is reasonable
to presume function A's security promises remained intact following
processing by
an arbitrary function B which does not have inputs available to it related to
the inputs of function A.   You cannot guarantee it 100%,  but a
mathematical proof is not the standard to extend security practices
which lower compromise probability.

You ignore added risks related to future quantum crypto development at
your own peril.
It's fine to only use PQC, but you ignore other risks the
implementation doesn't help you with,
also at your own peril.

The industry disagrees with you.
You'll find the approach appearing in various standards.
OpenSSH 10 already changed the default to a combination of ML-KEM
with 25519 ec  key exchange,  mlkem768x25519-sha256, etc.
Your rejection is soundly dismissed.

-- 
-JA