D312: 643_0001-Show-passphrase-constraints-errors-as-password-promp.patch

D311: 644_0001-Show-passphrase-constraints-errors-as-password-promp.patch

A few comments:

The special casing is take_this_one_anyway2 is wrong. Instead, in
check_passphrase_constraints, if failed_constraints is not NULL, we just
shouldn't call check_passphrase_constraints.

You also removed a translation.

You didn't update the copyright year.

You didn't include a signed-off-by line.

I've created a new patch.

Werner:

Some brief background: the Gnome people want one-button confirmations to appear
as notifications, which can be dismissed asynchronously. This patch changes the
passphrase constraint violation 1-button confirmation (when
enforce-passphrase-constraints is set in gpg-agent.conf), which should be
displayed as a synchronous dialog, to instead be an error text displayed with
the next password prompt. Independent of what one thinks of notifications, I
think this change is a usability improvement.

I'm sorry for the many mistakes.

In the commit message wouldn't it be:
"If FAILED_CONSTRAINT is not NULL and OPT.ENFORCE_PASSPHRASE_CONSTRAINTS is
TRUE, ..."

FWIW, there are 3 different use cases:

• Prompts about failed passphrase constraints: They do not need to me modal
• The prompt "Please insert card with S/N XXX" is really a notification and even gpg-agent will dismiss it w/o user interaction: No need to be modal
• "An ssh process requested the use of key ... please confirm" should IMHO be modal because it has the same purpose as entering a passphrase.

Werner:

The primary issue here isn't whether the dialogs should be model, but whether
they require the immediate attention of the user. Messages that don't require
the user's immediate attention should be shown asynchronously as notifications.
One-button dialogs are generally notifications, since they don't actually give
the user any choice. If a one-button dialog does require a synchronous
interaction then it is probably a bug.

Consider the bad passphrase case (and let's ignore the rest, since they are not
relevant to this issue). If we are not enforcing passphrase constraints and the
user enters a bad passphrase, then it makes sense to show a dialog. The user
has two options: "Enter a new passphrase" and "Take this one anyway"; GnuPG
needs more information from the user before it can continue.

If we are enforcing the passphrase constraints, then we currently show a dialog
with a single option: continue. The dialog is informational. However, the
dialog can't be shown as a notification: the user needs to know why he or she
needs to redo the enter-a-new-passphrase step. A background notification is
insufficient. The assertion is that this is actually a bug. This information
can be better shown in the enter passphrase dialog. That's exactly what this
patch does.

Do you agree with this reasoning? Can I apply this patch?

Thanks,

Neal

I've now pushed my version of this patch.