To add some (unrepresentative) statistics: My normal keyring contains 552 keys. 5 keys have a single revocation key. 1 key has 3 revocation keys.

What's the use case for multiple designated revokers? I don't think we should optimize Kleopatra's UI for something that's in theory possible with the OpenPGP spec, but which in practice will never occur for a productively used key. The standard use case is that the company wants to be able to revoke the keys of their employees, i.e. there will be a single revocation key.

I guess the status should be set to Testing?

In D545#6468, @sandro wrote:

Is supporting Python 2.7 such a high priority? That version of python is super duper EOL and this might be a good opportunity to drop support for it.

I have merged the changes for using setuptools if distutils isn't available. This fixes the immediate problem that the bindings couldn't be built for Python 3.12. I did not merge most of the changes in lang/python/Makefile.am because of the reasons mentioned above. Maybe we can address the open changes in another patch. In any case, thanks a lot for your patch! And sorry that it took so long to get some of it merged.

Sorry for the delay. I just had another look at the patch. Unfortunately, it doesn't work with Python 2.7.

/usr/bin/python2.7: No module named build

I think it's missing https://pypi.org/project/build/, but this package doesn't support Python 2.7 since version 0.6. Maybe installing version 0.5.1 of build for Python 2.7 would help.

Information about revocation keys can now be retrieved from a Key object (see T7118).

Information about revocation keys can now be retrieved from a Key object. Verified with internal test runners. Independent tests will be done with T7095.

I think it would be cleaner to create a separate ticket for making gpg fetch the requested key from LDAP.

Looks good

Assigning to Carl since he's working on this already.

Setting same priority as T6799.

We shouldn't change the name of the config file. The syntax is different from GnuPG's .conf files. Therefore it's better not to use the same file suffix.

I'm re-opening this ticket because I think this ticket only partially overlaps with T6799. T6799 is specific for g10 Code's releases of Kleopatra (especially for Windows) while this ticket makes sense for every version of Kleopatra.

In T7036#186290, @ebo wrote:

Tested with VS-Desktop-3.2.93.391-Beta:

Fixed and backported for VSD 3.3.

The texts were changed as discussed in the linked MR. I haven't changed the order of the buttons.

In the Qt 6 version the DeviceInfoWatcher can be enabled on Windows for A/B testing by adding the following config option to kleopatrarc:

[__Experimental__]
UseDeviceInfoWatcher=true

I have reverted the changes (also for VSD 3.3). I'll set this to open again and lower priority to low because the legacy file watching seems to work on Windows. We can revisit enabling the DeviceInfoWatcher on Windows when we have time to look into the root cause of T6688.

Hopefully fixed by disabling the DeviceInfoWatcher on Windows again.

I don't think we need a fallback. For the group configuration we can manually look in the old location. And for everything else it's okay to lose the configuration.

Problem is that this approach doesn't work for settings that are read/written by KF, e.g. the language settings if people change the application language. I also don't particular like the Krita approach of forking everything. On the other hand, patching Qt is also suboptimal and doesn't even work for builds we don't control. Maybe KConfig needs a way to override the default config location retrieved from Qt.

/include/linux/dirent.h defines

struct linux_dirent64 {
	u64		d_ino;
	s64		d_off;
	unsigned short	d_reclen;
	unsigned char	d_type;
	char		d_name[];
};

I think Kleopatra now respects the "disabled" state of OpenPGP certificates. I don't remember the outcome of our discussion about allowing to disable OpenPGP certificates from Kleopatra, but I think this should be split out of this ticket.