- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 25 2023
My very simple patch for this would be:
Wait,.. I misunderstood this issue B81CE112B26A8EA8BE7B95D2E375339BF4C51840 has no encryption subkey o.O
The Keyresolver did not allow me to encrypt to an S/MIME cert where the root CA was not in my trustlist.txt that was part of this feature to allow users to encrypt "non vs-nfd compliant" to such untrusted keys, like they would be able to also encrypt to untrusted openpgp keys.
Nov 24 2023
I am temped to put the VSD-3.2 flag on it and raise prio to high because of strategic reasons... So if someone has a cheap fix for this. Please go for it.
Similarly if you decrypt with a PKI BW card and the mimeviewer there are also no longer problems which again might be related that the internal states where somewhat disturbed by the loop in Kleopatra.
I retested this with the current beta and It works without problems. I somehow suspect that the permanent access loop from Kleopatra caused other Smartcard operations to be canceled. Since the test setup is not really good to reproduce to for Ebo I resolved this myself.
I tested it and for me the files are not deleted:
Since I have such a test card, I just tested it and the issue is indeed gone.
Nov 23 2023
Oh sorry, no that did slightly not make it in when I created the tarball for the current beta.
It is now: https://invent.kde.org/pim/kleopatra/-/merge_requests/75
I realized that for Qt6 the include qtextcodec and setIniCodec must be removed. I should probably ifdef them to make merging more painless.
Nov 22 2023
I thought I had tested this, too. But apparently I lost track of my versions and did not.
Ah sorry i did not read your two messages that analyzed this correctly before I wrote my comment I had not refreshed the page.
Nevermind, I realize the problem since we are in the constructor KAboutData::setApplicationData is set when the constructor returns. So it does not makes sense for us to already call KAboutData::applicationData in this constructor and update it in the constructor only to have it overwritten when the function returns. Wit the constructed KAboutData object. Doing it in a thread works because then the thread is run after the constructor initially set the the application Data.
So this is weird to me to describe. After merging: https://invent.kde.org/pim/kleopatra/-/merge_requests/72 It would no longer use the updated KAboutData from updateAboutDataFromSettings in the loadBackendVersions code. There it would see the original aboutdata and then set that with the added otherText.
We should really fix that quickly.
This is very much unrelated to any GnuPG code so I can say this is resolved for Gpg4win, too.
Nov 21 2023
So why not resolved?
For me it is like if you open a save file dialog. You want it to remember where you saved a file the last time you saved it. But if you just browse around and cancel it, it should not store that location.
Assigned to me for testing.
I think cancel should not save the settings. A case of "uuuh I clicked something wrong and now I am confused" -> "Cancel" -> "Phew everything back to normal". Is more valid then just looking around, canceling and then coming back later and expecing the same state. I would say this resolved.
@ikloecker I suggest giving up on this, I know that it is frustrating but it does not make much sense, it is probably related to some compiler settings / Qt cross compile issue and might be a bug in qt. Just do an old style connect and leave a comment that we will revisit this with Qt6. When VSD 3.2 is our last major release based on Qt5 we should not spend too much time investigating this which might be completely different (or not) with Qt6.
@ikloecker I thought about this some more. Why do we do the READKEY when we could look up the keygrips and see that we already have keys for this. That sounds to me like a simpler fix then changing how gpg-agent behaves here. Although I still think that gpg-agent is in the wrong to just overwrite and potentially delete softkeys here.
Nov 20 2023
Ok since this does not happen with other cards this is definetly a gnupg issue I just checked with a telesec card and the behavior there is different.
@werner I think this question is for you to answer. IMO these files should not be overwritten. I mean they could contain actual secret keys instead of just the shadow keys and then those would be overwritten, right?
Ah no I see the difference here. Instead of connecting to a lambda with no args 96da231f97eff9485f62ab925d81252f5f97fc31 connected to the functions which were used in the old signal / slot syntax. I think the fix might be to explicitly list the args of the quickjob result or to use afunction to handle the keygenresult.
It does not log failed connections but new style connections are never logged when they fail. Since they can't fail ;-)
Let me put this on the 3.2 workboard since we already have the "reports error when canceled" on that workboard and T6566 too depens on this, in fact I am currently working on this even though it was not on the workbaord.
Yes these files are rewritten on every iteration.