Please describe which features are missing.

Why do you compare the *gnome*-pinentry (GTK based with GNOME support) with the *Windows*-pinentry (plain Qt)? In fact the gnome pinentry delegates to the gnome-keyring-daemon and is as such integrated into the GNOME system.

Hey. As reference – Complete set of features while run in Windows.

Set of features while run in Fedora –
From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

"Once entering a password in only one field, be it the first or second, invoking OK starts an endless process. At this state,

1. Attempting to enter into the confirmation field a password won't be operational;
2. OK button wss greyed out, while Cancel button alone was available.

Some observations:
– OK button has been in my tests available for being invoked right from the beginning of the apparition of window illustrated by kleopatra_3.1.4_failed_password_setting_1.png while no passwords had yet been entered into any fields.

– The second field –the one aimed for password confirmation– was opened to receive some content even while the first field –the one aimed to enter a reference password– had been left blank. Yet during that operation, OK button remained available."

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

modern versions of gcr's prompter show a "password strength" bar anyway, but it doesn't use gpg's "strength" test.

testing the prompter via pinentry-gnome's invocation (with SETREPEAT, to ensure we get it entered twice), it behaves the way i expect it to. Hitting "continue" when the passwords don't match just shows the warning about how the passwords do not match (though i think some improvements could be made in that workflow too).

if there's an endless loop happening, perhaps it's due to how the wizard is invoking pinentry? can you be more specific about what you think is wrong?

You may find it easier to test pinentry on its own with:

printf 'setrepeat\ngetpin\n' |  pinentry

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

"more specific about what you think is wrong"; From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

"– OK button could be greyed out right from the beginning until both fuels have been supplied with some content which then make it at last available for being invoked.

– The second field could be closed, eventually adding a greyed-out background to it in order to make its state explicit, until a password has been entered into the first field and user has switched to the second field.

– Once both fields have been supplied with content, invoking OK button would process information contained within these fields then check that they match each other. In case they don't, a typical message related to the situation would be exhibited, such as "Passwords do not match each other.", but without the need to lead to a failure."

Produced interface from execution of 'printf 'setrepeat\ngetpin\n' | pinentry':

• case 1 – Passwords matches; No passwords

$ printf 'setrepeat\ngetpin\n' | pinentry
OK Pleased to meet you
OK
S PIN_REPEATED
OK

• case 2 – Passwords do not match

Steps: Do valid unmatched passwords by Continue then cancel operation by Cancel..

$ printf 'setrepeat\ngetpin\n' | pinentry
OK Pleased to meet you
OK
ERR 83886179 Operation cancelled <Pinentry>

• case 3 – Operation for entering passwords, takes more time than allowed

$ printf 'setrepeat\ngetpin\n' | pinentry
OK Pleased to meet you
OK
S ERROR gnome3.? 83886142 
ERR 83886142 Timeout <Pinentry>

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

The three suggestions above those cases are all suggestions that should be made to gcr upstream, since pinentry-gnome3 relies entirely on gcr's user interaction.

I don't see any specific action to take with pinentry itself here, i'm afraid. I know this can feel frustrating, but the chain of dependencies is pretty deep here. I'm not trying to "pass the buck", but one of the design goals of pinentry-gnome3, iiuc, is to let the user's desktop environment handle the UI as "natively" as possible, which means delegating the dialog box and almost all its behavior to gcr.

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

This might be true for the qt variant of pinentry, but for pinentry-gnome3, we've always been just taking whatever gcr gives, and not trying to force (or hide) the password quality bar. Other variants of pinentry have never had a "qualitybar" in the first place.

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

/* If a passphrase quality indicator has been requested and a
   minimum passphrase length has not been disabled, send the command
   to the pinentry.  */
if (pininfo->with_qualitybar && opt.min_passphrase_len )
  {
    rc = setup_qualitybar (ctrl);

@Rycky_Tigg: May I close this bug? You will still be abale to refer to it from a bug report to GNOME.

You may.. Comments were relevant. Bye.

Reported.