It will be hard to fix this. GnuPG supports exactly one class of regular expressions: something bracketed between "<[^>]+[@.]" and ">$" . Even if the next release of gpg supports more regular expressions, gpg will have to wait years before it can start emitting different regular expressions for scoped tsigs by default.

I just realized that my example is incorrect. It doesn't make sense to support multiple issuer subpackets on self signatures. But it is useful to do so on binary signatures and third-party certifications. Here's a better example, which gpg correctly supports. As such, this issue should be closed. Sorry for the noise.

This is more or less what gpgme does/sees when loopback mode is enabled / disabled:

All of the campaign videos have now been published.

Thanks for noticing this and working on a patch.

Hi marcus, the original motivation for the separate file was to avoid the use of floats, which, IIRC, Werner didn't want, because floats don't belong in a system tool. Nevertheless, your approach of avoiding a square root all together solves the problem quite nicely.

The sqlite backend was a little experiement that I did and it will not be merged.

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.

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

In T2905#98803, @justus wrote:

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