Btw, ecore-x was also needed, so that should remain. Just to be clear, the final version should be

PKG_CHECK_MODULES(EFL,[elementary >= 1.18,ecore-x])

Give or take the >= vs >.

@dkg it was the 2nd one, the EFL vs efl. That worked fine after uppercasing it! The >= may not be necessary, but might as well. I am on a much newer EFL, 1.25.1, so not really able to test that part of it. I should be running one of the latest autotools,

[ebuild   R    ] sys-devel/automake-1.16.3-r1:1.16::gentoo  USE="-test" 0 KiB
[ebuild   R    ] sys-devel/autoconf-2.69-r5:2.69::gentoo  USE="-emacs" 1,438 KiB
[ebuild   R    ] sys-devel/libtool-2.4.6-r6:2::gentoo  USE="-vanilla" 951 KiB

Looks like its missing an include

x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -pthread -I/usr/include/libsecret-1 -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/lib64/libffi/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include    -I/usr/include/ncursesw -I../secmem -I../pinentry -Wall  -O2 -pipe -march=amdfam10 -mcx16 -msahf -mabm -mlzcnt -Wall -Wno-pointer-sign -Wpointer-arith -c -o pinentry-efl.o pinentry-efl.c
pinentry-efl.c:32:10: fatal error: Elementary.h: No such file or directory
   32 | #include <Elementary.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.

@dkg for sure, I will test out the patch ASAP. Thanks for the ping.

This is known and by design, basically it is a legacy X feature. For Wayland, the window manager determines if a window should be blocking, no grab or grab, not anything applications themselves have control over. This came up many times when I was first making the interfaces. You can reference these two comments, but there are many more in between them.

@gouttegd Thank you very much!

No clue what their problem is, I have a few projects scanned by Coverity. Most are forks that I took over, but one is not really. Not sure why they took such issues here.

After fighting with Coverity over a fork of pinentry that has EFL. I setup to have Coverity scan. Which found some like 22 defects. Coverity unable to identify that I have any affiliation, after I spent/wasted hours getting a build to upload to Coverity to scan. Just to fight with some unhelpful person basically standing in the way of FOSS project, a wonderful Mel Llaguno. Decided for security reasons I be denied ability to use Coverity to scan pinentry for defects, even in the EFL interface I made and am the author of. Which also means I cannot fix other issues with pinentry or aide further in development....

Your welcome, I can remake another unified patch if need be. I was starting to prepare things to be a stand alone fork. Did an initial .travis.yml file, and initial stuff for Coverity. Though never did get a build uploaded to Coverity. Not sure if you have ever run pinentry through Coverity or other GnuPG stuff, may be a good idea just to see if it catches anything.

@werner no problem with re-opening. I closed as it seemed it was not of interest or wanted. I wasn't get any responses like asking why it was left out of 1.1.0 release. To my knowledge other than preferences of GnuPG devs, changes to suit your needs, grabbing, libsecret, etc. It should be good to go without any issues. Thus I was waiting next release, assuming it was already committed . May have confused it with some other PR that was committed. But there should not be any outstanding issues preventing it from inclusion. If there are it was never relayed to me. It should be ready for inclusion, less any requested changes.

@werner no clue, I thought it was merged in at some point. I could have sworn something happened there. I went on advising others like the TQT interface assuming EFL was already added. I was shocked it was not when release came out and no explanation as to why it was excluded.

Proceeding with a fork, and likely will remove other interfaces and just maintain another version of pinentry for EFL. Maybe renamed to pinentry-efl, and only have that and tty and curses interfaces in addition to EFL.

Moving on, I will just look to make a stand along project for efl-pinentry interface. I withdraw my previous submission. Welcome to resume and move forward with Mike Blumenkrantz version. Thanks!

Not sure this should remain open. Months later a release was done excluding this. Originally mentioned on list in October 2016. Over a year later still not included. Very discouraging. I guess I can just see about having this external for myself. Shocking that FLTK and QTK see more usage than EFL which is part of Tizen OS. Clearly issues with either me, or EFL. Some reason it was excluded and being ignored. Seems nothing I can do either way. Oh well, I did all I could for months. On a very small contribution...

I could have sworn a patch/pr was merged into repo or something. It seems it was not. Guess I must be mistaking it for some other contribution. Guess I will give up on trying to get EFL into next pinentry release. Which may take another year or so. Despite the fact I have been using it daily for many months now. Oh well.

Why without it was already committed to repo? Is there some problem I
am not aware of?

The --grab/--nograb to my knowledge has nothing to do with the handling of the DISPLAY variable. Which is not used by Wayland. I believe Wayland uses WAYLAND_DISPLAY. @4tmuelle you may want to open a new task on the DISPLAY variable handling.

Any update on this? Ready to do a pinentry release?

In T3279#101995, @gouttegd wrote:

Password quality evaluation is actually performed by the GnuPG Agent, not by the pinentry programs

In T3279#101865, @werner wrote:

Grabbing the keyboard is an important X feature and not related to gtk etc.

Hilarious! Not sure if its best to re-comment or edit. Seems phab has edit ability so I tend to do that... I need to slow down and re-read before setting sail :)

Just corrected :)

I think a decision should be made about grabbing. Since the gtk pinentry interface seems to be the only one that does grabbing. I need to confirm again, but last I checked, as commented on list, Wayland lacks any grabbing specification or ability. Making this a X only feature of GTK. It seems the patches 1 2 for this are for xwayland, not regular wayland stuff. Which seems to be why bugs like this one on RedHat are open.

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.

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.

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.

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.

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.

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.

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

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?

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.

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

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.

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.

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?

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

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.

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

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!

Forgot EFL version...

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

Updated diff, swapped out legacy api function

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

What version of the patch or EFL?

I sent the DCO per request.

Switched to dialog from window. Relocated call to center window. Which may not be correctly centered till release of EFL 1.19.1 due to a bug in EFL itself. I thought was a bug in my code. Thus previous patch.

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.

Minor changes, switched to dialog. Modified code to fix centering issues that may be a bug in EFL itself.

I have updated the code and patch. It is ready for review, modification, and ideally inclusion

Cleaned up code format some. I fixed issue when display is not present and fallback to ncurses. This should be good to go now. Pending review, other issues, reformatting etc.

I have noticed some issues, minor code fixes, and a major issue with failing to fall back to tty/ncurses interface when a GUI is not available. I will make the changes, cleanup the code format, etc and re-attach patch.

The underscores on the Cancel and OK button come from Pinentry. Not sure if I am not handling Locale correctly, or something along those lines. The other stuff does not have it, and setting text the same way.

Sure thing, and it is "semi" animated. If you fail to enter a correct pin/passphrase. The error message is animated, it will slowly move back and forth from left to right. I can provide further screenshots of its various options, confirm, quality, double entry, etc. The quality bar changes color from red to green, with every shade in between based on quality, 0 red, 100 green, in between other colors/shades between the two.

I changed it back to EFL from Enlightenment. Enlightenment is a desktop/application coded using the EFL. Like Gnome is coded in GTK. This does not require Enlightenment at all. Just the EFL. Which can be used in GTK/Gnome, or KDE/QT based environments just the same. Also Tizen, etc. Thus I would not call it Enlightenment anywhere, as it really has no relation.

I created the requested differential. Please let me know what I need to do for inclusion. Thanks!

Ok I will do that soon as I am finished with refinements and it is ready for re-submission. Thanks!

I got the patch from Mike. It does need some refinements. I will work on the modifications and re-submit. Do you accept PRs on Github? Or should I attach here? Or send to mailing list? Thanks!

I am interested in this, and can look into any needed polishing. Can someone please attach the patches to this bug or a link to where they can be downloaded. Unfortunately mailing list archives strip attachments. I spoke with Mike in IRC who informed me he made a EFL port of pinentry. I was working on that, and still have my code going in case I cannot get a copy of Mikes work. I am willing to do what ever is necessary to get this into pinentry sooner than later. Though I understand it can take some time. Hopefully not the 1yr it took the FLTK based pinentry to be added.