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.

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.

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.

I agree with @dkg, and something should be done to address this one way or another. It is pretty misleading.

In T2905#99092, @dkg wrote:

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

fwiw, i also find this password quality indicator rather dubious.

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 .

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.

• marcus (Marcus Brinkmann) <noreply@dev.gnupg.org> [20170622 16:41]:

So, the default change 7y ago and the world didn't end. Closing this.

@werner What's the status here?

So, the default change 7y ago and the world didn't end. Closing this.

@werner do you have any updates on this?

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.

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.

So does the "modern" branch actually have this feature? And which version
in particular would you recommend I test? I don't seem to have any newer
build available in my distro (Ubuntu 14.04), as this version is what I'm
getting when I run "gpg".

This is a feature request for the 'classic' branch. We will not implement any new features there. Please switch to GnuPG 'modern'.

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.

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?

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!

(and without saving the password to disk or entering it on the commandline, both of which less secure)

@gniibe , I was happily running scdaemon 2.1.21-beta73 for more than a month and it properly relinquished the card every time. However, a few days ago it got hold of the card and would not let go (or at least, other users of the card got "sharing violation" error from pcscd). I collected some debugging information:

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

Yes, if it supports --card-edit it would help a lot.

Updated the patch should be good to go now

Fixed as of 525f2c482abb6bc2002eb878b03558fb43e6b004.

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

In T1983: gpg2 prefers missing secret key to available key on card, I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.