In T7262#195642, @ametzler1 wrote:

I read this as bumping the version-number e.g. from 1.24.5 to 2.0.0 without e.g. bumping the soname or changing the api_version as specified in the .pc file. (FWIW I think that is a great plan.)

The title says "notepad". The description says "clipboard". What do you want?

Additionally permanently watching the clipboard for changes can cause some password managers to detect an "attack". As it is discoverable which application accesses the clipboard on windows we had the case where a password manager would not work when Kleopatras clipboard watcher was running. T6642

We'll do this with QGpgME 3. And it's easy to add new functions by using the NVI pattern and, if needed, virtual functions in the attached private classes. I've been using this technique for quite some time now.

Ah, ok I understood it as "we will change the soname for other reasons e.g. so that both versions are co installable but we will not break ABI". And I would prefer the break for qgpgme at least because of the mentioned problem not because I don't care about ABI stability but because I do and this is a big problem which only exists, because I didn't do it with the last repo move. There is no technical reason anymore for the abstract base classes.

Werner wrote:

We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility.

If the major version for QGpgME is bumped, shouldn't we at least remove the virtual base classes. Eg: delete FooJob and rename QGpgMEFooJob to FooJob. I did regret not doing this when i moved them out of libkleo since this architecture no longer makes sense in the standalone libnrary and technically the virtual bases make it nearly impossible to maintain ABI stability when adding functions. The reason for those was only because libkleo had that idea of different backends namely gpgme and chiasmus. But a Library called QGpgME should never provide another backend then GPGME IMO.
So no behavioural change at all, just something to make future ABI compat easier.

I think we have to use multiple different texts instead of assuming that we can use something general as "Detailed import results from %1" which fits all cases in all languages.

ok, then we leave it in the certifications tab like it is.
What about the Uid tab? Keep it like it is, which is: Name, Email, Trust Level, Origin, [Tags] ?
While I do not think that the origin need to be shown by default, I don't think it's really a problem, as this is the last column

Pushed the change for adding hash tests in rC7faf542f1573: fips,tests: Add t-digest.

My comment referred exclusively to Tobias's "In the future [...]" comment.

"Tags" are stored with certifications. Therefore, I think it's useful and makes sense to show the Tags column in the Certifications view.

This is what Tobias means:

Isn't the name of the tab showing the imported certificates "Imported Certficates" or something like that? The filter "All" shows all imported certificates. And when you select the filter OpenPGP you see the subset of imported OpenPGP certificates. Therefore, I don't think it makes sense to add a custom filter.

Gpg4win 4.4:

Some questions (wishes):

• Will the upload also be done to an configured LDAP Server?
• Can the upload-checkbox setting be configure via the Windows registry?

Gpg4win 4.4: ok, now the date of the main key is preset as the expiry date of the main key if it is less then 3 years in the future. Otherwise 3 years from now is preset.

Ok, I'm not asked, therefore I set this to done, but not resolved yet, as I'm not sure if the gpg version might have an influence.

Gpg4win 4.4:
Contrary to the task description are:
a) In the certifications tab the "tags" column is shown by default
b) in the UID tab, the "origin" column is shown by default (only the "tags" column is hidden)

The only difference that you should see in the UI is that there is no longer a menu that pops up when you drop files, asking you what to do with the files. So I guess, if things works fine as you described them, you can consider the ticket done

This ticket description does not give me anything to test.

tested with Gpg4win 4.4

tested with Gpg4win 4.4

This issue looks still the same from the user perspective as in the task description with Gpg4win 4.4. Therefore tagging it for gpd5x

It seems that the internal API (as of 2024-12-06) is not enough.
Now, we have _gcry_md_hash_buffer function with the new FIPS service indicator.
It's used for public key crypto, too.
The compliance for hash function is a part of public key crypto, but not all.

A change for gcry_md_hash_* functions are pushed by rC3478caac62c7: fips,md: Implement new FIPS service indicator for gcry_md_hash_*..
It doesn't have tests with FIPS service indicator yet.