Whether the confirmation dialogs are shown is configurable in the config file (just like any other "Don't show again" option, e.g. the question asked when you quit Kleopatra). Simply remove the corresponding entries in the [Notification Messages] section to make Kleopatra show the confirmation dialogs again.

KMail is using QtWebEngine even for plain text content. The entire viewer is one website, which causes some security issues like content from one mail can position itself on top of the headers information with simple css.

Works, the confirmation is asked in all 3 cases.

So with my ryzen 9 on tumbleweed:

It works for the standard use case where we have keys with one user ID.

So priority Normal for "have a way to show html in QTextBrowser" and after that move it to prio low. Our SecOps explicitly state that HTML mails should be avoided.

For now I am for the KMail approach with QTextDocument. So if we have multipart/alternative show a button that HTML is available and then the user can decide (e.g. if the mail is validly signed) to render the HTML part in QTextDocument. This might give us also an idea how well this works overall. And then let us wait for now until we get to the real GpgOL.js use case. For the customer we talked today is a bit special in that he mostly wants to have a way to view decrypted mails in Outlook. That is something we do not want to compete with.

For comparison, this is the debugview output if I don't give the passwort on import of a X.509 certificate, were the ü is displayed correctly:

Done in https://invent.kde.org/pim/libkleo/-/merge_requests/52 but requires a way to fallback in mimetreeparser when we detect that the file is actually not an email file or make this behavior optional

Done in https://invent.kde.org/pim/mimetreeparser/-/merge_requests/20

Changing the prio to normal as we have this now and want to improve on it.

The second retry counter is used by current cards for the Reset Code error counter. It is zero if no reset code has been set. It was used by card specs 1.x for the CHV2 only available there.

with VS-Desktop-3.1.90.258-Beta the ü is still broken for "Zeitüberschreitung" in the error window which occurs in the context of keytocard:

So I tested upgrading from 3.1.26.0 to the current beta and it also did not work.

This may be related to the output PIN retry counter : 3 0 3, i.e. the PUK counter is 0. No idea what this means.

The same is true for trying to unblock the card with the PUK. Again I have to enter 3 PINs in 3 windows before being informed that the entry in the first window was wrong. Additionally, the text in window 1 is borked

If you try "Change PIN" next, you will be asked for the PIN and 2x for the New PIN in altogether 3 pinentry windows before being informed that the PIN is blocked.

After the 3rd entry of the wrong PIN, this is exactly the same.
Here I would wish for not only the popup "wrong PIN" but additionally this popup should declare "PIN blocked".

This is inconsistent, as usually a separate window would pop up for pinentry errors.

I want to have this for the next release since I want to use that mechanism for the promised "Tender version of Kleopatra". This will mean that we replace the "VERSION" file with a QSettings ini file where we can easily add more meta information as we like.

While I want to investigate the syntax error in URI since I don't think the testkolabs have a syntax error in their URI the behavior you are describing is completely correct in my understanding:

thanks for your reply
gpg -K
gpg: enabled debug flags: memstat
/home/usernet/.gnupg/pubring.kbx
uid [ absoluta ]
uid [ absoluta ]
ssb cv25519 2022-02-13 [E]
gpg -h
gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

For reference, here is a link to the gpgme homebrew formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/gpgme.rb

Just to clarify, PIP wasn't used to install the .egg package. The package was built and installed via Homebrew. The error message occurs when using basic PIP commands such as pip list or pip freeze. PIP is picking up the gpgme egg from the shortcut included in the site-packages directory.

as this really bugs me, I raise the prio.
And add the Kleo tag, as Werner said it might be that Kleopatra is responsible.

Fixed for Sign/Encrypt Files/Folders and Sign/Encrypt notepad.

Fixed for Sign/Encrypt Files/Folders and Sign/Encrypt notepad.

It is a bit hard for us to decipher the Spanish diagnostics. Before we can try to help you please update to a deent version of gpg and libgcrypt. At least the version for Ubuntu is way too old; Libgcrypt is 5 years old, the current version of the lTS branch is 1.8.10. GnuPG is also 10 years old and in the mean time we have fixed several critical bugs; the current version of this legacy branch is 2.2.41! Note that Ubuntu might have fixed some bugs despit ethe version number - we just can't know.

We don't use or suggest the use of PIP or other insecure software distribution systems.

I found a regression for @item --version; It emits \[en]version for roff.

Pushed my fix to support them.

Hello,
I will send the logs as soon as possible.
Thank you.
Daniel

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.