- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 31 2023
werner do you have any idea based on the information from the original report where we could start looking for this?
I also see this from time to time, mostly when the keyring is empty or very small. But never was able to reproduce it. I thought this might be fixed with keyboxd but if you say that scdaemon might be the culprit then I might misunderstood the issue and it is not the keyring loading that is stuck but maybe rather our configuration initialization which queries the config of each component and is also part of the "Loading certificate cache.."
Thank you. I think it is good that we have now the time to attack some of these more difficult problems :) I don't understand the code there so don't expect a review from me.
Jul 30 2023
Oh wait. That shows a Problem in our side. We should include the full chain in our signature. I am renaming your task and will at least investigate if we do or if that maybe changed the last time we updated the certificate. Which might have been after 4.0.3
Jul 27 2023
I won't go so far to try to fully implement RFC2231 in the rfc822parse. But I have an idea how to implement this in a secure and robust manner in rfc822parse without touching the parser or the token stuff. My idea is to treat them as seperate TOKEN and then combine them in query parameter just for name and filename values.
Jul 26 2023
Right, I had briefly uploaded a "GnuPG-Desktop" appimage but then realized that for the gnupg.org download site the "GnuPG-Foo" was actually the correct version. Werner and me discussed the future of that version and there will be some changes for future releases which I won't go in there. But functionally it is the same, only the VERSION file differs.
From my side this can be closed. In Kleopatra we can maybe check for some more MIME types and then use GPGME_ENCRYPT_NO_COMPRESS but that is unreleated.
Jul 25 2023
@ikloecker I think your logs contain only false positives, I do not know that we use any defines created by config.h. Maybe for gpgme_off_t but even so when I moved gpgme++ and qgpgme from kdepimlibs into the GPGME repo I did not add any defines to configure for that.
Fixed with c6e16e403744ca39a24a38f38264865019c0cb93
Hi Carl,
yes I saw that test case. Btw. I don't really think that this comes from Outlook itself otherwise I would have seen this much earlier, the current MIME Parser in our Outlook Plugin is about 8 years old. Currently this comes through some kind of AppleMail (server?) application to the customer.
Jul 24 2023
I realized again how bad the current implementation is last week when Alexander managed to send a mail to me encrypted with a completely unrelated key.
a) It was not clear to him that he encrypted to a totally different key because it only displays the keyid
b) He somehow managed to store that key for me in the addressbook
c) He again selected something like "always encrypt to this user" in the dialog without realizing the consequences. This created a contact for me in his personal address book (invisible to him because he said he does not use the addressbook and in there all sources were unselcted) which had the wrong keyid (again only the fingerprint there) and the setting "always encrypt to this user"
@jukivili Good to know.
My vote would be to invert the logic of the last patch and add "no-hashing-in-parallel" as a compatibility flag and make the other behavior default and then to push it at least to master or even to 2.4.
Jul 21 2023
BTW. The icon is breeze "view-sidetree" which I found fitting to split a larger opaque MIME structure (e.g. an encrypted mail) into different parts.
I have added an observer repository for mimetreeparser here. So you can now use the keywords like "GnuPG-Bug-Id:" and your commits will be visible here on the platform. We can later switch the "upstream" URL to something else of course. https://dev.gnupg.org/source/mimetreeparser/
I am not really a fan of this. I can respect this as a wish but it is currently not my vision. What you are really asking is basically that we lead the private users into sending encrypted mails without knowing that they are doing it. This will lead to frustrated users who then blame KMail for their bad user experience.
Jul 20 2023
Jul 19 2023
Fix pushed to the 23/07 branch and master.
Jul 18 2023
I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.
Jul 14 2023
There are some more surprising results like on my windows test keyring it would always report "5 new signatures" regardless of how often I ran the script ;)
In T6379#172803, @ebo wrote:Noticed in gpg4win 4.2.0-beta373:
For Brainpool and ed/cv25519 keys it is not possible to move a subkey to a smart card with Kleopatra. The error message is "invalid value".
Moving the main key works, though. The command line works for all keys types, of course.
Jul 13 2023
😂 I literally laughed when I saw this. You are taking this so much further and faster then I expected. Great job!
Jul 12 2023
Normal priority to get the _1_ removed when no folder with the same name already exists in that location.
Strangely enough this does not happen on linux. Maybe related to the KMime changes we have there?
For S/MIME archives the output for e.g. testfolder.tar.gz.p7m is now named "testfolder.tar.gz_1_/testfolder" with the "_1_" even added if there is no "archive.tar.gz"
Jul 11 2023
Jul 10 2023
So some more data from 2.4.3. Once unpatched and once with your patch.