All build artifacts are accessible, e.g.: https://jenkins.gnupg.org/job/scute/ws/XTARGET/native/obj/tests/test-suite.log

So both gpg and gpgv seem to return success (as in the exit code is 0) if the signature is correct, even if the key is revoked or expired:

Note that the documentation clearly says that --nameserver expects an ip address. Now we could make it accept a port too, but that would not make the OP happy, as he wants to talk to localhost, but in tor mode, all dns requests are routed through tor (this is actually one of the main motivations for using a custom DNS resolver).

In T3240#99654, @im0nde wrote:

Neverthenless, I would be interested in other solutions that allow me to keep gnome-keyring installed alongside, as I would like to use it for other applications.

This is very odd indeed. Here is my guru log, it is the same as yours, but except of dying of the assertion, it just continues:

Andre merged this already.

Merged.

Merged.

Merged.

3DES is indeed an allowed cipher, so that is not a concern. Changing the cipher to something that is not allowed does not work.

This is not specific to Python, and it may not even be a bug in GPGME, but in gpg. Needs some more investigation.

Fixed in 1e68f93dc547ae75b921e43db35e3599de92e2cb.

This is a bug tracker, not a support forum.

I only get checksum errors:

Well, while this program looks very clean, it is very incomplete, I had to hack it to make starttls work, and I have not been able to send a single message using it :(

In T3236#99866, @aheinecke wrote:

In T3236#99865, @justus wrote:

The whole "GnuPG System" section?

No, only the options that are marked as "advanced" by gpgconf.

Actually, Andre has some uncommitted changes that do implement the wanted behavior. AIUI those mainly needs a little fix to so that it wont break with old GPGME versions. Once merged, I will amend it further if necessary.

"aheinecke (Andre Heinecke)" <noreply@dev.gnupg.org> writes:

"aheinecke (Andre Heinecke)" <noreply@dev.gnupg.org> writes:

The mockup in the design document shows a completely redesigned key selection dialog. I did not see anything like that currently in Kleopatra. Is that right or did I miss the new dialog somehow?

No I don't recall any such problems, sorry.

@marcus ping

This actually uses the same infrastructure.

I implemented a key filter that is used to modify the key appearances. For now I use a light green for compliant keys, and a light red for non-compliant keys. One could as well introduce an icon with the same method (i.e. it is easy to change), but aiui the icons are already used to display trust levels. Patch is pending.

I now display the compliance status d for the decryption process. Patch is pending.

Disregard my comment above. I now display the compliance status for every signature and for the decryption process.

I patched Kleopatra only to offer compliant options in the generation dialog. Patch is pending.

Relevant upstream patch submissions:

Unfortunately, the configuration dialog does not work at all for me. It says "The shared library was not found.", but it fails to say which library was not found.

The compliance with VS is stated in the tooltip. Is that sufficient or shall we make it more prominent with a background color?

There is a tooltip saying "May be used for VS-compliant communication." for compliant keys, is that enough highlighting? Or shall we give those keys a light green background color or something?

So I started with this one because it was the easiest. To reduce message fatigue, I only display compliance information if gnupg is in co-de compliance mode.

Is this about the gui not offering e.g. the wrong algorithm or key sizes in the first place? If so, then we have to either hard-code it in kleopatra, or communicate it from gnupg. I guess at this point, we'll have to hard-code it :/

In T2905#99181, @wltjr wrote:

With all that said, if someone could let me know how you want me to proceed, 2 options.

1. I add the 2 lines to make EFL function like others, 1 char = 10%

No, that is the convention used by gpgconf. See https://gnupg.org/documentation/manuals/gnupg/Format-conventions.html#Format-conventions:

I'm going to close this task now. If we need more options to be configurable, it is easy to open another task for them.

It fails the very same way:

Kleopatra for now only shows TOFU info in cert details.

In T2905#99086, @wltjr wrote:

Even with that being said I see no difference here

gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (qualitybar),  (double)percent/100.0);
elm_progressbar_value_set (qualitybar, (double) percent / 100.0);

I am not seeing anything that would make the percent for GTK be any different than percent for EFL.

The GTK code is basically the same as my EFL code.

Neither change the percent value. GTK does only if it is below zero. Which seems like a hack, make a negative value positive?

else if (percent < 0)
    {
      ...
      percent = -percent;
  }
...

Maybe that where the difference comes from. I am not making that value positive. Seems based on werners comments about 10% per char would go inline with that. If percent is returning a negative value, and they take that and flip it to be positive. But that is not correct. It is not qualifying the quality of the entry.

I am comparing your work with the gtk pinentry as shipped by Debian. Maybe Debian is shipping a patched pinentry, I don't know, and frankly I don't care.

If this is gone in master, please close this bug. Thanks :).

In T2905#99020, @wltjr wrote:

I just tested this out. It seems to be based on what you enter and what is returned from Assuan/Pinentry. If I enter, 2 spaces, then a 1, and repeat that pattern. By the 6th space, you get 20%, and from there it increments by 10% or so to 100% as you continue to enter space space 1,

space space 1 space space 1 space space = 20%
space space 1 space space 1 space space 1 = 30%
space space 1 space space 1 space space 1 space space 1 = 40%
space space 1 space space 1 space space 1 space space 1 space space 1 = 50%
.....

Try entering in that, and you should get the exact values above. I can type in a full sentence 0%, but soon as I hit a single number, it jumps to 80%.

Fixed in 273964798592cd479c111f47e8ce46d5b1999d6a.

In T2905#98816, @wltjr wrote:

The quality bar should be working, please try typing in more characters till it does something. It should at some point.

In T2905#98810, @neal wrote:

In T2905#98807, @wltjr wrote:

With regard to quality algorithm, I assume I do not need to do anything there? I can adjust the math for the percentage aspect. But that is based on what I get back from pinentry so if that is off, it maybe what is effecting the quality of the quality bar :)

No, you should not adjust what you are getting. My point is only that the password quality bar may not only be useless, it may, in fact, be dangerous.

Not being compliant is better than breaking existing users.

In rG3621dbe52584bc8b417f61b5370ebaa5598db956#44388, @werner wrote:

On Wed, 21 Jun 2017 12:02, noreply@dev.gnupg.org said:

I really do not understand that critique.  First of all, the
comments for these functions clearly state what the predicates

(It was an example). Yes, the comments stated that but we had no idea
why this is needed.