Yesterday
Mon, Apr 22
Tue, Apr 16
What is the current status of this issue?
Mon, Apr 15
Thu, Apr 11
I had wrong interpretation about symmetric cipher algorithm identifier in the draft. It specifies symmetric cipher for the following Symmetrically Encrypted Data Packet (I was wrongly interpret as if it were specifying algo for AES keywrap).
Wed, Apr 10
I merged the change by Werner to get the value from frontend.
Tue, Apr 9
In the current code, just for testing against the test vector in m https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02, there are specific value in the key combiner KDF.
Namely, the value 105 for fixedInfo is defined in the draft (and it will be changed).
Fri, Apr 5
I created a pubkey (actually a subkey) for your above test keys:
I use this for testing:
Mar 25 2024
On March 11 and 18, the private key file DE1AB1D22899CEC7DBB1A7863F34E6E92BFB7756.key was wrong.
I updated on March 25. Now, the endian is GnuPG (d is big endian).
Mar 23 2024
Thanks, that patch works for me.
Mar 18 2024
I extracted data from https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02 and compose x25519 key and MLKEM768 key. Here they are.
x25519 :
MLKEM768 :
Mar 7 2024
As a first experiment, let us use CIPHERTEXT in the format of (enc-val(ecdh(s%m)(e%m)(k%m))) (s: encrypted-session-key, e: ecc ephemeral key, k: kyber ephemeral key).
Mar 1 2024
In 2.4 we have rG1383aa475 which does
Pushed the change in: rGf50c543326c2: agent: Allow simple KEYINFO command when restricted.
Feb 29 2024
No, thank you both for the speedy responses :)
Thanks a lot for your quick testing.
The commit rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. of GnuPG 2.2 introduced this bug.
Feb 26 2024
Jan 26 2024
Dec 21 2023
I see the reason.
Dec 19 2023
FWIW: These days a thread on Linux is not that costly but nevertheless takes up resources. On other Unices (and WindowsCE) threads have quite some overhead and that was the reason I implemented it the way it was.
Nov 20 2023
works, VS-Desktop-3.1.90.287-Beta
Nov 15 2023
So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.
FWIW, the Fileversion is actually the Git revision in decimal
b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/
a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:
So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.
Nov 14 2023
Nov 12 2023
Ok closeapplication will not work because:
Nov 10 2023
Note to self.
So some research led me to believe that using taskkill from MSI is not uncommon. But most stackoverflow solutions did not work for me. I have one solution that works, though but that opens a terminal window for each process we try to kill. I don't want to use wscript to avoid that, since an installer that executes visual basic is IMO even more evil then an installer that executes taskkill. Both are not really the MSI way, but while we could fix our processes without a WindowMessage loop to die nicely this will not work for an upgrade to vsd32.
Nov 3 2023
So I tested upgrading from 3.1.26.0 to the current beta and it also did not work.