Well, I am using pinentry-gtk2 1.0.0 on Awesome, and I just performed some tests with master as well.

I'm not sure if this post ever made it into a bug report, but has master been tested with tiling WM like awesome to see if issue is fixed? https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032608.html (if not I'm sure robbat2 is helpful enough with that if picking up the thread)

@justus Are the FLTK and the EFL ready for a release (which we could mark as beta test versions)

Well, the backlog is here: pinentry

Users expect to be able to make signatures (or to fail to make signatures) reliably and understandably. the fact that some pinentries fail in some obscure combinations of circumstances makes the process of making signatures unreliable and incomprehensible.

What behavior do you expect in this case?

The Debian report includes multiple workarounds for the quite unusual setup. So, I am closing here.

And SETQUALITYBAR.

Is this even something that we can control? This stuff is usually up to the window manager, and although some accept hints, this is not really well defined. For example, gcry_prompt_set_caller_window accepts a window-id-string and says:

It is unclear what the benefit of such a console pinentry for windows would be.

Loopback is now officially supported, so I am closing this.

This seems to depend on the window manager. With Fedora 26 and Gnome 3 desktop, a full grab is not allowed anymore, and there is no close button on the modal dialog. With i3 and pinentry-gtk-2, the grab is strong but there also are no close buttons.

I tested this with Fedora 26 and the Gnome 3 desktop. and could not reproduce this. So maybe it got fixed upstream.

I just tested this with Fedora 26, pinentry-gnome3 0.9.7 and Gnome Keyring 3.20.1. See below for a full trace. If this doesn't work for you, check that you have compiled pinentry with libsecret, and did not deactivate the feature in the gpg-agent.conf.

pinentry-curses on the same terminal as the application was never intended to be automagical - from the start it was clear that during any operation that may trigger a pinentry dialog, the application would have to stop reading from the terminal, and it would have to redraw the screen when gnupg finishes. That's just a limitation of the terminal that can not be overcome (there is no focus grab, no save/restore of the terminal state, etc). This needs to be raised with the emacs developers.

Except for some tangential lingering questions, all issues in this report are attended to, and all subtasks are resolved.

Done in e57bcb7a2acff3a61a342d24e6a55407bf736631

This was resolved upstream by using no-grab (and otherwise would rather seem to be a bug in Gnome 3 classic mode anyway).

That issue is best taken up with the enigmail maintainers. If you report it there, feel free to add a link here. Thanks!

I can't reproduce this in Fedora 26. If this is still an issue, please reopen and provide more information. I tested pinentry-gnome3, pinentry-gtk-2 and pinentry-qt.

Fixed in 6053cb4f. The third patch was obsolete due to use of FIND_QT macro.

Done.

I can confirm this behavior with the latest pinentry-gtk-2 under the Awesome window manager.

In T2905#99236, @justus wrote:

There is nothing to fix in the way the underlying algorithm communicates its value to the frontend. Negative values mean red, positive values green. After that, you have to normalize that to 0...100.

Added hack to negate negative that move progress bar 10% per 1 char. Fixed issue with new line characters not being handled correctly.

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%

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

Looking further into this, pinentry_inq_quality can return a value in the range of -100 to 100. Thus getting -10 from pinentry_inq_quality seems quite normal. Which explains why each are doing <0, since the value can be less than zero, negative quality.

I am pretty sure I understand it clearly. If I add those two lines it makes the EFL version function like the others. Without it does not. I just debugged this on first character entered, pinentry_inq_quality returns -10. Which again negating -10 becomes 10, and thus the first character gets you 10%, and continues from there.

In T2905#99112, @wltjr wrote:

Let me clarify, what all are doing now to make the progress bar move is the following

if(percent<0)
    percent = -percent;

That inverts the value if below zero a negative with 2 negatives become positive. That ends up moving it 10% per 1 character entered. That is the code mine does not have. I have tested it with that code and it functions like all others.

Once the password algorithm is corrected. That if condition should not be hit long as the returned value is greater than 0. The value, in theory will always be above 0. HOWEVER, if it is below zero, legitimately from what ever is checking the "quality" of the passphrase. Then this will be a bug in all. Since it will revert to old behavior, every wrong character entered that causes a negative value to be returned, will hit that condition and move by 10% per 1 character.

That means at best the code becomes useless code for a condition never hit. But at worst it cause the same behavior as seen now even with a new algorithm, a bug. If something returns negative values for bad entries.

Thus I rather leave out code that would become obsolete/useless, or potentially cause the same behavior with a corrected algorithm. Which will happen now for all the other interfaces.

Said another way, the only thing that should make the progress bar move in any is the "quality" value. The use of percent for the value is the hack. Because the quality value cannot be used. They grab the percent value and increment based on number of characters.

Let me clarify, what all are doing now to make the progress bar move is the following

if(percent<0)
    percent = -percent;

That inverts the value if below zero a negative with 2 negatives become positive. That ends up moving it 10% per 1 character entered. That is the code mine does not have. I have tested it with that code and it functions like all others.

In T2905#99108, @wltjr wrote:

In T2905#99092, @dkg wrote:

T2103 is the right place to discuss the password quality algorithm, not here.

Sure but that issue is seeming to cause issues for this contribution.

If you want to not implement the password quality indicator for the EFL pinentry (which seems like a reasonable choice to me) then it would be in line with pinentry-curses, which also doesn't implement it, afaict.

It is currently implemented and I do not have a problem leaving it as is. The question then becomes a matter of its functionality. Do I leave as is, for when the password quality algorithm is fixed? Or should I make it like the others?

It is really up to you all. I am just trying to get this accepted. If you want the EFL version without I can remove. If it is to remain.

In T2905#99092, @dkg wrote:

T2103 is the right place to discuss the password quality algorithm, not here.

T2103 is the right place to discuss the password quality algorithm, not here.

In T2905#98804, @neal wrote:

The password quality algorithm is a joke and is probably more dangerous than helpful. (Try entering the password 12345678...) AIUI, it was added because a client had a specific requirement. I'd prefer that we either fix the algorithm (complicated and depends on the user's threat model) or we deprecate the quality bar.

Just confirmed it is this that causes it to move 10% per char, and is wrong IMHO

if(percent<0)
    percent = -percent;

I have also noticed that there is a line return after "to" before protect. Which explains why those words run together on the EFL version. I will have to see about replacing the new line characters with something that works for EFL. It does not support new line characters in labels.

This seems so wrong... entering 1's and a's This would fail a lot of sites that require minimum stuff on passwords like upper/lower, number, special character, etc. This makes NO sense for a quality meter to say junk is quality. Think others have hacked around this. It is not correct.

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.

Even with that being said I see no difference here

Ok I just tested this out and BOTH GTK and QT are messed up. Maybe the others as well. I have to check FLTK and not sure about ncurcses/tty. I simply typed 10 characters and I got 100%. It did not matter what those 10 characters were at all. Like 10 of the same character. That is not correct!!!! That is not saying what I typed was of any quality. This functionality is completely jacked in all. No wonder my version is having issue. Seems others hacked around this broken function and eliminated the entire purposes of qualifying an entry.....

Wait, you said Debian maybe patching YOUR code to fix an issue? Maybe get the patch and apply to pinentry and correct the issue werner found in pinentry. Rather than going off on me for something I have zero control over.

You do not care about comments in T2905#99021? So werner is completely incorrect there? He stated something is wrong and GTK is effected as well...

FYI I use this daily as I have been since my first submission. Gentoo ebuild I made which uses the patch. Why would I make that if I am not using? Every commit I make is GPG signed.

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.

In T2905#99071, @justus wrote:

No I wont. I'm constantly testing your code. Please read my feedback. I'm growing a bit impatient with you, because I feel like you are developing a piece of software that you are not using, because as soon as I test it I instantly find problems with it.

This is even more worryingly because you actually have multiple pinentries to compare with. The gtk version clearly behaves very differently wrt the quality bar. You need to fix this.

Please re-read my feedback. For example, if you enter "1234567", the gtk one says in red 70%, whereas yours says 0%.

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%.

I have updated the patch in D426, direct link to it on Github, to address the compiler warning from comment T2905#98802 .

Fixed issue with ok_len

../../efl/pinentry-efl.c:493:7: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
       int ok_len = ELM_SCALE_SIZE(strlen(txt) * (PADDING * 1.5));

ok so I just need to fix the compiler warning and we should be good to go. Was there anything else I needed to address?

Here is the code:

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,

Why I was saying maybe my math is off or something. I am doing basically the same. Should be the same code. I calculate the percent exactly as they do for GTK. I also set the value the same. Maybe something I am not doing correctly in EFL.

gpg-agent waits for a QUALITY inquiry via Assuan from the pjnentry and replies with an integer giving the percent value. A negative percent value requests "red" indication. The argument for the quality inquirement is the passphrase as already entered. The idea is that this inquiry is send after each keystroke.

Nobody started to hack on it in two years, and buried in this bug report nobody will find it. If this is still a desirable task, a new ticket should be opened.

It's not possible, unless you convince the Emacs developers to add special support for it. See http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00798.html.

I used this workaround for the years I accessed my mail over ssh and emacsclient.

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 many cases, it's possible to make two connections (e.g. via ssh) to such a server, and in one of those connections explicitly do:

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

Note that it depends on a gpg-agent configure option. Thus Neal and you may see a different thing.

No, the quality bar is required for pinentries which want to get in wide use. Even if the quality algorithm seems to be too trivial, it is required for external checks like gpg-check-pattern.

In my tests it worked, you just have to type a decent amount to get it to kick in. It seems to accelerate really quick, like it jumps from 0 to 60% and then 100%, not really smooth from 0 - 100, as intended. But I think that is due the quality value returned from Pinentry.

In T2905#98811, @justus wrote:

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.

So currently the efl bar always displays 0%. It must either be fixed (i.e. display the same as the gtk one), or be removed. I don't care either way, but it cannot be broken like it is now.

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.

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 :)

How is that icon by the way? Like the key better than the lock/shopping bag? :) The icons will change based on the users selected icon set.

I will fix that warning, I should have caught that, I do no think I am using that compiler flag/option.

In T2905#98803, @justus wrote:

The password quality bar is not working. There are spaces missing in the texts.