it would be great to include a test in the test suite that ensures that the --status output behaves as expected in the face of expired or revoked keys.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 7 2025
Mar 6 2025
Please use "unbreak now" only for *released* software with a criticial bug.
Feb 5 2025
I think there's some confusion.
changed the workboard to gpd5x as this is still the case in Gpg4win 5.0-Beta versions.
Feb 3 2025
Jan 8 2025
Got a simple fix for this which does two things:
- Correctly act upon an error from the backup file writing
- Print a warning note.
In T2169#196673, @werner wrote:Shall we handle this with additional retry prompts, w/o a timeout? I think this makes sense because creating keys with a backup file and a passphrase is a manual task anyway.
There is a regression due to the regression fix in rGb30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7 (from Dec 24 2015) or some related commits:
Jan 6 2025
Dec 5 2024
Dec 2 2024
Closed, since this was documentation for the workaround, four years ago.
Just a reminder: with Gnuk 1.2.15 and an ed25519 key PubkeyAuthentication unbound is required for hosts using the new feature.
Nov 29 2024
Fixed in 2.4.6.
Nov 25 2024
For this ticket, I reviewed the code around my SOS changes.
Because I'd like to focus the point of retaining binary representation when doing import->export,
I created another thicket: T7426
Nov 20 2024
thanks for the clarification. i was not objecting to the workflow, i was trying to understand so that i can interact with the bug tracker appropriately. I was unaware of the difference between "milestones" and other project tags. I'll try to get that right in the future.
Please do not add milestone tags.
Nov 14 2024
I put "scd" tag and let me claim this ticket.
Nov 12 2024
Nov 8 2024
For Beta-75 it looks similar judging from my first tries.
Nov 7 2024
I managed to get the same "loading certificate" message several times in a row on this test instance by stopping and starting Kleopatra in a row twice. After removing the Signature Card 2.0 this did not happen again in 5-6 tries, although I collected 2 lingering listing processes again (not both started on the same startup). Even import of a X.509 certificate worked.
Next I managed to have one gpg and one gpgsm process each left over from the last execution of Kleopatra.
After starting Kleopatra new anyway, again "loading certificate cache" and an additional pair of gpg and gpgsm listing processes start.
Had a occurrence of the never ending "loading certificate cache" issue again.
There was a leftover gpgsm process from the previous tests (although Kleopatra warned when I closed it, that processes still running in the background were there and would be aborted).
Nov 5 2024
Nov 2 2024
Nov 1 2024
@ebo Thank you for your continuous testing.
Oct 31 2024
Unfortunately, this seems not to have ended the sporadic hangs.
I just saw a hanging initial keylisting with gpg4win-beta-70 which has gpg 2.4.6
Oct 29 2024
Backported to 2.4 to go into 2.4.6
Fix backported to 2.4
Oct 24 2024
Passing ticket to werner to consider backports.
Oct 17 2024
Oct 9 2024
Oct 4 2024
Tested with VS-Desktop-3.2.94.2-Beta.
Works as expected on the cli.
Oct 2 2024
gpgme should handle lists correctly. In Kleopatra those options are not shown in the configuration dialog because they are GC_LEVEL_INVISIBLE, i.e. Kleopatra can read them programmatically but they are not shown to the user.
Oct 1 2024
In T6882#191854, @werner wrote:While testing this I noticed that only the last adsk or trusted key is listed. Thus several assurances of this options are not properly represented. See T7313
Fixed for master. Let's first test this with kleopatra.
Done for 2.2. It is already in 2.4.
Sep 27 2024
Will do.
It is reproducible bug even with master branch.
Sep 26 2024
werner: Can you also backport listing of "default-new-key-adsk" with gpgconf so that Kleopatra can check whether a default ADSK is set?
Backported to 2.2
I have a look at the log file of gpg-agent.log. I can see that six PKDECRYPT requests are handled simultaneously. I think that it's out of secure memory to decrypt the private key which results pinentry request.
Sep 25 2024
We won't do that for Windows.
Fixed in 2.2 with: rGc33523a0132e047032c4d65f9dedec0297bfbef3
Sep 24 2024
Please go ahead and apply to master. I'll take then care of backporting.
Sep 20 2024
Found another thinko; When there is no clients with DEVINFO --watch, the pipe to be notified is not consumed at all (no read). It eventually results blocked by write(2), when the pipe is filled.
Sep 19 2024
I see. the systemd race of having two gpg-agent processes. The second gpg-agent should eventually go away but than it is already too late.
I mean: two gpg-agent requests simultaneously running DEVINFO --watch.
Single scdaemon, two threads handling DEVINFO --watch simultaneously, by pselect + read.
Two threads waken up, but it was only one thread which can read(2), another was blocked (before the fix).
Sep 18 2024
You mean it is possible that the initialization function is called by several threads - or that two scdaemon's are running before they realize that one of them is in the way?
I realized that I put a bug on POSIX; When multiple clients do DEVINFO --watch, it is possible for scdaemon to hang (waiting pselect and read, read by one, read by another is blocked).
Sep 17 2024
Fixed GnuPG 2.4 in: rG730593affa91: common:w32: Don't expose unused functions.
libgpg-error fix is done in: rEc2a713fe11e3: w32:spawn: Remove unused function get_max_fds.