For a very long time i would have agreed with you. But i now understand the usecase. You misunderstand that feature just like i had. It is not about checksum verification or checking. It is for detecting changes in folder trees so that you know when to reencrypt and update your encrypted archive of that tree. Yes this could be done somewhere else but the usecase is valid for kleopatra.

I would rather like to see the checksum stuff be ripped out of Kleopatra into a simple standalone app. It's complete overkill to start the Kleopatra battleship if the user just wants to calculate or verify a checksum of a downloaded file. The UI of the checksum tool in Kleopatra is anyway still not accessible (T6099: Kleopatra: Make checksum verification accessible). How about we redesign the UI from scratch with accessibility in mind from the start?

I have a NextCloud instance where I can simulate a bunch of users sharing calendars to investigate and test this.

Ah i und erstand what you mean now. Btw while checking this i found it confusing when i opened the incidenceeditor on an event in somone elses calendar. It did not show the correct organizer or even attendees. But this indeed might be caldav related. I would like to give you access to our radicale instance but i think it is in our VPN and so only the actual employees may access it (not even ingo)

The difference is that you can have an event in your calendar that you are neither an organizer or an attendee (think someone forwards you an invite) yet you will likely still want to receive a reminder for that.

The tobias/gpgsum branch in gnupg now contains my implementation of this. Together with the attached patches to kleopatra and libkleo, it can properly handle unicode filenames on windows. I'll put those patches up for review at KDE in the next days.

works with VS-Desktop-3.1.90.258-Beta

With VS-Desktop-3.1.90.258-Beta I ran again into the last issue with "Wrong PIN". I had not realized that I had entered the PIN wrong before (as you have to enter the PIN several times anyway when generating a new key on a card and you do not get an error message on wrong PIN but instead only a new pinentry window...).

works

with VS-Desktop-3.1.90.258-Beta, CSR creation is now greyed out for RSA2048, while it is offered and works for other algorithms

CSR creation works now (tested with VS-Desktop-3.1.90.258-Beta, Yubikey and OpenPGP card)

The changes affect:

• State of "Clipboard -> OpenPGP Sign" action in tray icon context menu
• Selection of signing key in "OpenPGP Sign Clipboard" dialog
• Selection of encryption key in "Sign/Encrypt" via dialog
• Selection of recipients in "Encrypt Clipboard" dialog
• Usage information in tool tips for certificates in main certificate list

In master, when fixing padding issue, libgcrypt/src/const-time.h is just introduced.
I will replace your functions.

Eva tested a few expiration dates for new keys: For 2038-01-18 the date is correct. For 2038-01-20 and 2106-02-05 the expiration date of the new key is 2038-01-21 and 2106-02-06 respectively. Kleopatra passes the date as ISO date.

hmm, almost. With VS-Desktop-3.1.90.258-Beta I do not get an error any more, a key is generated. But the "vaild until" date is off by one day, it is one day later as the one given at key generation.

works, the secret part is now imported, too, tested with VS-Desktop-3.1.90.258-Beta

update error{F5228116}

works: my brainpool X509 testcertificate is shown as compliant

For the VSD branch it works, VS-Desktop-3.1.90.258-Beta

In VS-Desktop-3.1.90.258-Beta it is "no space left on device" now in the encrypt/verify window.

It works, thanks!

Should work now. Please test if the auto-detection works. (Tumbleweed builds Qt 6 without "reduce-relocations", so that I cannot check it on my system.)

Small correction: On my/our system (Tumbleweed) the test without -fPIC always succeeded, so that -fPIC was never added. That's why I removed this useless test which, as it turns out, wasn't useless on your distro (@dfaure-kdab Which distro are you using?).

In T6776#177536, @dvratil wrote:

Makes total sense, but I'd like to think about a more general approach if possible - what e.g. Google or Outlook do when you add someone else's shared calendar is they don't send you invite for their events either. But it's not because they wouldn't notify you about events where you are not an organizer, because in many cases you are just an attendee of someone else's meeting in your own calendar and you definitely want to get reminders for those.

Nah, forget it in that case. I might report a bug to SUSE in that case but we should not invest in fixing such things. I was planning to either use a self compiled PIM stack or Flatpack anyway.

Makes total sense, but I'd like to think about a more general approach if possible - what e.g. Google or Outlook do when you add someone else's shared calendar is they don't send you invite for their events either. But it's not because they wouldn't notify you about events where you are not an organizer, because in many cases you are just an attendee of someone else's meeting in your own calendar and you definitely want to get reminders for those.

You are right this looks like a bug in libical. I tried to downgrade to 3.0.16 but still can't reproduce the crash. But I also noticed that the line numbers from your backtrace do not align with upstream code. IIRC you are on Tumbleweed, right? They have some downstream patches in the parsing code (vcc.c) that probably cause the crash: https://build.opensuse.org/package/show/openSUSE:Factory/libical