Well, we always have to weigh the costs with the benefits. From the description of the task, the benefit was to satisfy "people [who] really don't like having idle processes lying around", which is not a strong motivation to take implementation and maintenance cost of any solution.

This is a disappointing resolution. There are many other reasons for having a daemon, which include keeping a sensitive piece of data in memory (and not on disk) for a limited period of time, while providing controlled access to it. This is exactly what gpg-agent does.

Thinking about it more broadly, i think that gpgv (and gpg, when used in signature verification mode) should have a return code that is as close to the true/false underlying semantics that users will want, rather than relying on status messages to distinguish between these cases.

for expiration (or for revocations flagged "key was superseded" instead of "compromised"), you can have a signature made *before* the key's expiration/revocation, but you might be verifying it *after* the key was revoked/expired.

Sorry, I expressed my concern poorly. gpg does recognize the keys as being expired/revoked, but this is not reflected in the exit code of the gpg/gpgv process.

Werner's comments indicate that this is expected behavior. Also, concerns were raised that this is difficult to implement correctly, and it is difficult to test. So, I am closing as wontfix.

And SETQUALITYBAR.

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.

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.

Without a strong use case, I am closing this feature request. It may well turn out that like --allow-emacs-pinentry, the best solution in each case will be to add specific options, and then a generic pass-through will never be required. And we don't want to add features just in case somebody might need them in the future.

I don't think that's what we want. An OpenPGP certificate has a claimed temporal validity window: from the creation date of the certificate to its expiration or revocation date.

Done.

So both gpg and gpgv seem to return success (as in the exit code is 0) if the signature is correct, even if the key is revoked or expired:

We don't support pkg-config, because it is not POSIX. See https://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028474.html for discussion.

Given that we have reduced the number of operations to at most 2 (down from unlimited), and it is unclear if and how to proceed on this, I am closing here.

Fixed in rD1143a81c4691.

FWIW, OpenPGP's S2K and PKCS's PBKDF2 are very similar and don't make a difference except that we have calibration code for S2K in gpg-agent.

The TOFU trust model gives some more information about certificate usage. Beyond that I don't think this is well defined to be actionable in the backend.

Digicert TERENAPersonalCA3 doesn't use issuingDistributionPoint anymore. It's hard to survey CRLs that are actually in use, so I don't know if there are other important users, but the fact that nobody else reported such problems is an indication that it is not widely used among dirmngr users. Supporting this is a lot of work, because it makes validating certificates much more complicated, so this is unlikely to happen without strong motivation, so I am closing this here.

I removed the man page and the link for now. Currently there doesn't seem to be an easy way to update it automatically.

PGP/MIME is supported since Gpg4win 2.3.

Most people should use a graphical user interface, and the console gui for key generation doesn't ask too many questions, while the key editor allows to go "back". So I am closing this suggestion.

Still no better message with gpg 2.1.21:

Maybe this can be done by Neal along with the book?

The change werner mentioned previously is eaba8d58acda66f428870794115cb22c2590ec5e, but this is based on Elgamal. RFC4880 since then specified S2K, and better approaches are available, too (at least PBKDF2 is in libgcrypt). These could be used with HKDF for RSA and other asymmetric key generation methods.

gnupg 1.4 is phased out and only receives important updates.

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.

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