- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 29 2023
Yes, works now ( VS-Desktop-3.2.0.0-beta from today):
works, I only see the error in debugview.
Furthermore, I use the occasion to point to T6493, Improvements on search window ;-)
Under Kleopatra -> Settings -> Configure Kleopatra -> GnuPG System -> In the Tab Secret Keys -> Is there either "Delete unused Passwords after N Seconds or Delete Passwords after N Seconds set to zero or the option "Do not use the password cache for signing" set? In this case this would be normal and expected behavior because it turns of the caching.
Thanks for the report and the helpful suggestion. I was anyway about to change the time format but your suggestion is better.
I am not sure whether we need to fix things in kleo but at some places gpg uses atoi() to parse the seconds since epoch. This should be fixed because that is the way gpgme provides the expiry time. I will also look into the ISO date string parser.
works: After generating a PIV key
gpg --edit-card
nevertheless shows the OpenPGP keys. Tested with gpg4win 4.2.0.
Sep 28 2023
Aha, so you know how to provoke us into action, good man ;-) Alright I give it high priority. No seriously, makes sense to have we'll see when we can fit it in. Needs an extension in our internal api so probably not in the next release but sooner rather then later.
Maybe it's due to the fact that I used a non-admin installation? Actually I'm also surprised that it worked that way. What kind of debug logs could I supply?
works as described
Mmh or even select all expired keys and then refresh them.
Multi select makes this nontrivial. But I think only with multi select this would really be useful. But yes it is a nice item for the backlog. E.g. if you know that a company switched their mail domain you might want to refresh all the keys from that company and you could do that with filter + multi select and refresh.
For me with Gpg4win 4.2.0 it works as expected, that is all UIDs which have a checkmark are certified in one go, entry of password only once. Used the key given in description for the test.
After the fix everything after the Signature block is now silently discarded
Changing debug options unfortunately didn't change much.
works
works
The certification of certificate groups (first two points of T6469#174361) is mostly done.
Sep 27 2023
OK, so after debugging the issue and finally digging into the code I realized that I don't see the fix I did the first time....it turned out I committed the fix to release/23.04 branch but forgot to merge it into master and as such the change did not make it to 23.08 - which is probably why it seemingly "came back" after you upgraded. I've cherry-picked the fix to release/23.08 branch and merged it to master.
works
This can be resolved I tested this myself and gave a beta to the affected customer which also worked for them
works, VS-Desktop-3.2.0.0-beta214
This is NOT the bug reporting form. You will find the form at https://dev.gnupg.org/maniphest/task/edit/form/5/
In T5903#176176, @ikloecker wrote:Please submit a separate feature request for this.
In T5903#176175, @uwi wrote:I'm late on the train, but (talking about Kleopatra) there is a menu entry to refresh all keys, but I miss a RMB (right mouse button) context menu for the list of certificates to refresh just the current one (much similar like the feature requested, but "one UI level higher").
I'm late on the train, but (talking about Kleopatra) there is a menu entry to refresh all keys, but I miss a RMB (right mouse button) context menu for the list of certificates to refresh just the current one (much similar like the feature requested, but "one UI level higher").
Edit: The text below was wrong. The error given below only occurs when the combined path+filenmae is to long on windows.
An emoticon in a file below the folder to be encrypted does not hinder encryption via GpgEX.
It's been a few years since this task has been active.
Sep 26 2023
Here's another data point.
works, tested with VS-Desktop-3.2.0.0-beta214.
For the remaining issue with a certain date range see T6736