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.

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

By the way, when terminating pinentry with "kill -TERM ...", it shuts down correctly, while CTRL-C show "gpg: signal Interrupt caught ... exiting" and a corrupt screen layout that is reset when pressing RETURN, further confirming the above diagnosis.

The problem seems to be that the CTRL-C is sent to gpg, terminating it, but pinentry keeps running and interfers with the terminal. With "ps -j" we can verify that pinentry runs in the process group and session of gpg-agent, while gpg runs in its own process group within the shell session. So, the signal rightly goes to gpg.

I updated the patch, fixed all issues mentioned and a couple others I noticed. Things not being centered vertically labels/entries, and ok not being fired on pressing enter on entry, or confirm when present. That should fix all outstanding issues.

Various fixes

• Fixed confirm passphrase intial text, was label text...
• Fixed button length with long text
• Fire ok on pressing enter in entry or confirm if present
• Call focus on entry last, attempt to fix focus
• Vertically center labels with entries (minor were aligned to top vs center/middle)

In T2905#98415, @justus wrote:

So are you also saying that I should better not use e17 because its focus handling is so fubar that it does not focus the pinentry when it pops up?

Thanks for the input. You need to understand that this ("keyboard grabbing") is actually a security feature. If you don't like it, you can disable it (using the pinentry option --no-global-grab), or you can switch to a pinentry without that feature (e.g. the qt one).

In T2905#98127, @wltjr wrote:

I got your point, I was saying do not have a chat client or program that would create pop ups and grab focus away. Its a highly debatable and personal preference type of thing. I have run into such already.

@justus Can you tell me how you got the two passwords with extra text and the long button text? I can replicate the long button text via cli. Not sure about the two passwords and extra unwanted characters. I would like to be able to replicate as you did. Thank you!

Marcus: That would be a good opportunity to get back to your old curses works ;-)
IIRC, we fixed similar bugs in the past but this is for the latest pinentry.

I got your point, I was saying do not have a chat client or program that would create pop ups and grab focus away. Its a highly debatable and personal preference type of thing. I have run into such already.

In T2905#97872, @wltjr wrote:

Ok I can add the keyboard/mouse grab stuff. I have the code already. I get your point, mine is the opposite of yours. I would say don't launch something if your typing in your pin or about to :)

Updated the patch should be good to go now

• Fixed issues with underscores in button text
• Fixed issues with warnings
• Added news item
• Fixed issue with show/hide changing size
• Replaced icon, fixed missing button icons

Ok I can add the keyboard/mouse grab stuff. I have the code already. I get your point, mine is the opposite of yours. I would say don't launch something if your typing in your pin or about to :)

"wltjr (William L Thomson Jr)" <noreply@dev.gnupg.org> writes:

I will see about removing the underscores now that I understand their meaning. I am not sure if EFL has any means to interpret such at this time. I will look into it and address either way. Thank you for that information!

Ok, so the patch from the differential works. Could you please address these warnings?

In T2905#97835, @wltjr wrote:

I am not sure where the underscore comes from. Seems to come from pinentry, but GTK and QT do not have that, so I think its something I am doing wrong.

Forgot EFL version...

Ok you should be good to go now. There are 2 issues I am aware of.

Very sorry! I already fixed that. I just had not updated the patch. This one is updated
https://github.com/Obsidian-StudiosInc/pinentry/commit/0fb3104c3ab27112aad70668c5828f9d435e10d4.patch

Also, would you be so kind to add an item to the NEWS file?

"wltjr (William L Thomson Jr)" <noreply@dev.gnupg.org> writes:

What version of the patch or EFL?

Cool, thanks. Can you please explicitly say what version is the current one?

I sent the DCO per request.

Hi @wltjr, thanks for picking this up. If we want to merge your code, we'll need a DCO from you. If you agree, please send https://dev.gnupg.org/source/gnupg/browse/master/doc/DCO to gnupg-devel@.

I have not looked at this since I did some work on the pinentries, but if noone fixed this then yes, it is still an issue. Indeed, I just quickly read over the source:

Justus, is still still an issue?

If the dialog's show a bit off centered. The center of the screen being top/left of dialog. Which makes it offset to the bottom right. That is a bug in EFL (T5481) that is fixed and should be in EFL 0.19.1. Not anything related to this code though I did try to address in this code.