After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 688434 - Modal password boxes prevent users from looking up or generating passwords
Modal password boxes prevent users from looking up or generating passwords
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 686531 688295 689663 700057 700930 704674 708333 709513 731588 732659 734070 738232 741989 743763 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-11-16 02:47 UTC by Adam Williamson
Modified: 2021-07-05 14:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Williamson 2012-11-16 02:47:06 UTC
(with apologies to the ragecomics community)

This is similar to https://bugzilla.gnome.org/show_bug.cgi?id=660293 , but it's the general case - this can happen with _any_ case of the Shell password entry dialog, it's not limited to that specific NM case.

GNOME 3's password entry prompt blocks access to anything else, which is presumably for Security and stuff. Great. Except I keep all my passwords in a password manager (Revelation). It's great fun to be sitting looking at a password prompt, with my password manager visible right behind it, from which I could get the password the fricking prompt wants me to enter if only it would let me *click on it*.

Milan writes in https://bugzilla.gnome.org/show_bug.cgi?id=660293#c1 :

"I guess the use case is that the first time you enter a password/key, you'd
like to copy it from a text file? But in that case, you can still copy it
beforehand, and then connect to the network, get the dialog and paste it. This
means you need to know what you're doing, but typically if you're copying the
password/key, you do."

Which is all very sensible, except I am a stupid squishy human with a fallible squishy human brain and I can tell you that this is _reliably_ not the case. I almost never remember to go and get the password before the prompt for me to enter it pops up. On almost every login session, reliable as clockwork, I run 'git pull' on some Fedora-related repository, see the password prompt come up, and gnash my teeth because I didn't copy the bloody Fedora ssh key passphrase before running the command. So I hit esc, go to revelation, copy the password, go back to the terminal, hit up and then enter, and finally enter the password.

This costs me about ten seconds, but it's every damn session, and it annoys me without fail every time.

I am not smart enough to come up with a design that would allow this without just making password prompts normal windows, but surely someone else is. A special class for password management apps that lets you access them when the password prompt is active, perhaps?
Comment 1 Allan Day 2012-11-16 09:45:28 UTC
In some respects, this seems like a general issue with modal dialogs. I don't know how we are going to get around that.

One obvious thing we could try and do is make sure that passwords of this nature are remembered rather than you having to enter it each time.
Comment 2 Adam Williamson 2012-11-16 17:46:08 UTC
well, the security policies on ssh passphrases are pretty standard. if you have it remembered permanently it's barely a security measure at all.

I do kinda like the idea I tossed off yesterday, though obviously it might be considerable work for someone who is not me :) imagine a really shiny interface where there's a password manager that integrates with GNOME's password dialogs cleanly and tightly, that'd be kind of awesome.
Comment 3 Milan Bouchet-Valat 2012-11-17 21:32:47 UTC
I really don't get the point about Revelation. Is it reinventing gnome-keyring? Why? If you accept that a password manager stores your passwords somewhere, I really don't see why you would prefer copy/pasting them from an external app rather than having your apps automatically retrieving them from the keyring...

That said, there's indeed a more general problem with modal dialogs when you need to copy the password from somewhere else.
Comment 4 Adam Williamson 2012-11-18 00:43:01 UTC
Milan: I use my passwords from multiple devices, including non-GNOME devices. A proper password manager has import/export capabilities to facilitate this. I don't believe gnome-keyring even has the ability to share my passwords between GNOME systems, far less anything else. Password managers can generate the password for you with multiple options, store associated data like usernames and URLs, and save passwords for websites (which is mostly what I use it for). The app re-locks after a short timeout, which improves security - even if you happen to steal my laptop while it's unlocked, chances are decent that the password manager is locked. I can't do any of that easily/at all with gnome-keyring AFAIK.

If gnome-keyring/seahorse could grow full-fledged convenient generic password management capabilities that'd be awesome, but I don't believe they currently do.
Comment 5 Milan Bouchet-Valat 2012-11-18 20:50:14 UTC
OK, I see now. But since Revelation specifically targets GNOME, I think they should be able to integrate with gnome-keyring/seahorse/libsecret, or merge with it, as the GNOME philosophy mandates, to get the best user experience. Anyway, manually copying passwords is clearly suboptimal from their POV.
Comment 6 Adam Williamson 2012-11-19 00:32:48 UTC
revelation isn't under terribly heavy development at present, I don't think. I'm not at all tied to revelation as such, I just need a decent password manager, and revelation happens to fit the bill for me atm. as I said, if GNOME wants to grow good native generic password management capabilities via a rejuvenated revelation or any other way, that would be awesome.
Comment 7 Giovanni Campagna 2012-12-02 23:42:34 UTC
*** Bug 686531 has been marked as a duplicate of this bug. ***
Comment 8 Milan Bouchet-Valat 2012-12-05 08:28:34 UTC
*** Bug 689663 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Nickurak 2012-12-05 14:23:33 UTC
Here's the case I run into all the time: I use Google's 2-phase authentication. It's awesome. You get the perfect something-you-have+something-you-know authentication. For applications that don't support it, you get to generate long per-application passwords that can be individually revoked. You just go into your account settings in your browser, log in with the 2-phase authentication, and generate a password. Awesome.

Except that you can't do this once an application has asked for a password. Evolution's got an incorrect password, and prompts for a new one every time I log in, but I have no way of getting the new password while it's asking for it.
Comment 10 Adam Williamson 2012-12-05 18:23:39 UTC
jeremy: damn you, give me back my ragecomic summary! :)
Comment 11 Jeremy Nickurak 2012-12-05 18:29:24 UTC
I appreciated the sentiment... but searching bugzilla is bad enough without joke titles. (which is why I filed a dupe...)
Comment 12 Jasper St. Pierre (not reading bugmail) 2012-12-05 18:31:48 UTC
(In reply to comment #10)
> jeremy: damn you, give me back my ragecomic summary! :)

We all have to make sacrifices sometimes...
Comment 13 Jeremy Nickurak 2013-04-09 21:28:13 UTC
*** Bug 688295 has been marked as a duplicate of this bug. ***
Comment 14 Jeremy Nickurak 2013-04-09 21:29:46 UTC
Any workarounds available? Any way to make it non-modal, temporarily or
otherwise?
Comment 15 Adam Williamson 2013-04-09 21:39:26 UTC
my workaround is still "swear, smack the desk, hit Esc, copy the password, then do it again", sadly.
Comment 16 Milan Bouchet-Valat 2013-05-10 12:50:42 UTC
*** Bug 700057 has been marked as a duplicate of this bug. ***
Comment 17 visitor932304 2013-05-20 11:57:14 UTC
Here's a (quite stupid) workaround I came up with. I often work at locations where there may be people peeking over my shoulder, so I don't want to type the password, or have the password visible on screen at any point. I keep my passwords at another system so I wrote a small wrapper script.

#!/bin/bash
(sleep 1;my_script.sh key_id)&
# now do something that might trigger a gnome password prompt

my_script.sh retrieves the keyring password from another system and copies it to the clipboard using xsel (and clears the clipboard after another delay). Subshell is used, because using a small delay seems to be necessary for the paste function to work.
Comment 18 Milan Bouchet-Valat 2013-05-25 09:43:08 UTC
*** Bug 700930 has been marked as a duplicate of this bug. ***
Comment 19 alex 2013-05-27 18:39:54 UTC
I have an idea how to solve this and a related problem (people will insert garbage into password prompt if they type):
make password prompts to notifications. And let them flash up on click or if ecplicitly triggered by user
Comment 20 alex 2013-05-27 18:42:11 UTC
and there should be a possibility to push it back in the notification area
Comment 21 André Klapper 2013-07-24 09:13:58 UTC
*** Bug 704674 has been marked as a duplicate of this bug. ***
Comment 22 Jean-François Fortin Tam 2013-07-24 14:50:20 UTC
+1, to which I'd add, for the specific case of wifi network passwords, that they should not be obfuscated (bug #667370).
Comment 23 Adam Williamson 2013-07-24 15:57:47 UTC
Just to keep the momentum rolling, it's 8 months since I filed the bug and this still happens to me _every day_. The 'train yourself to remember to copy the password before doing the action that triggers the prompt' thing is _not happening_.
Comment 24 André Klapper 2013-09-19 09:01:13 UTC
*** Bug 708333 has been marked as a duplicate of this bug. ***
Comment 25 Matthew Barnes 2013-10-06 16:18:11 UTC
*** Bug 709513 has been marked as a duplicate of this bug. ***
Comment 26 Andrew McMillan 2013-11-13 06:29:21 UTC
Any action on this?  I have hundreds of passwords in my password safe, accumulated across years of logging into many, many systems.  And now the upgrade to Gnome 3 has forced this modal dialog on me, while at the same time (it seems) that Evolution regularly decides the remembered password must be wrong if some temporary network failure occurs with my ISP.

I really can't remember five different 20-random-character e-mail account passwords!  And then remember them all again for outbound SMTP as well :-(

Then if I "Cancel" on the dialog so I can open my password safe, I can't seem to get it back except by quitting Evolution and restarting it!  Convoluted indeed.
Comment 27 David Strauss 2014-01-03 00:18:59 UTC
Here's another issue: application-specific passwords. Google is now using these with two-factor authentication. The passwords are long, random, and intended to be copied+pasted into the application that needs it.

Evolution currently has an awful workflow for this unless you copy the password to your clipboard at the perfect time, knowing the modal is about to come up.
Comment 28 Milan Bouchet-Valat 2014-01-03 11:45:25 UTC
(In reply to comment #26)
> Any action on this?  I have hundreds of passwords in my password safe,
> accumulated across years of logging into many, many systems.  And now the
> upgrade to Gnome 3 has forced this modal dialog on me, while at the same time
> (it seems) that Evolution regularly decides the remembered password must be
> wrong if some temporary network failure occurs with my ISP.
> 
> I really can't remember five different 20-random-character e-mail account
> passwords!  And then remember them all again for outbound SMTP as well :-(
> 
> Then if I "Cancel" on the dialog so I can open my password safe, I can't seem
> to get it back except by quitting Evolution and restarting it!  Convoluted
> indeed.
Please file a bug against Evolution. This will at least mitigate the problem.
Comment 29 André Klapper 2014-01-03 12:01:21 UTC
(In reply to comment #28)
> Please file a bug against Evolution.

Bug 709513 is marked as a dup of this one.
Comment 30 Milan Bouchet-Valat 2014-01-03 15:19:26 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > Please file a bug against Evolution.
> 
> Bug 709513 is marked as a dup of this one.
Yeah, but this is wrong, at least for the first part of the report. Evo should not ask for the password when there are network problems, and it should only ask for it in response to user action, so that you can predict when you will need the password.

Please file a new bug against Evolution, as Bug 709513 is already old.
Comment 31 Jeremy Nickurak 2014-01-03 16:00:16 UTC
I should note that this problem is certainly not limited to Evolution. Gnome-shell/NetworkManager will also spotonaneously pop up a password dialog in some situations of intermittent connection problems. (Just hit this a minute ago on Fedora 19, gnome-shell 3.8.4.
Comment 32 Milan Bouchet-Valat 2014-01-03 20:28:47 UTC
(In reply to comment #31)
> I should note that this problem is certainly not limited to Evolution.
> Gnome-shell/NetworkManager will also spotonaneously pop up a password dialog in
> some situations of intermittent connection problems. (Just hit this a minute
> ago on Fedora 19, gnome-shell 3.8.4.
Yeah, but please also file a bug. Even if password dialogs weren't modal, popping them out of the blue is never a good design.
Comment 33 Milan Crha 2014-02-04 16:24:04 UTC
To get more sane password prompts, as a workaround, edit your sessionMode.js (I have it at /usr/share/gnome-shell/js/ui/) and delete from there 'keyring' string from components of 'user' session (together with its corresponding comma) - there is only one such string. Then restart gnome-shell.

This way, you get the password prompt, which can be minimized (if you miss the icon on the title bar, then use the right-mouse button above the title bar to get the context menu), but the most importantly, you can interact with the session and copy passwords from any other application (which allows copying it, of course). Enjoy.
Comment 34 Florian Müllner 2014-02-04 16:45:52 UTC
(In reply to comment #33)
> To get more sane password prompts, as a workaround, edit your sessionMode.js 
> and delete from there 'keyring' string from components of 'user' session 

It's worth noting that this stopped working in 3.10 (removing 'keyring' means 'no keyring dialog', not 'fallback keyring dialog').
Comment 35 Milan Crha 2014-02-04 19:32:15 UTC
(In reply to comment #34)
> It's worth noting that this stopped working in 3.10 (removing 'keyring' means
> 'no keyring dialog', not 'fallback keyring dialog').

Well, I tested the change in Fedora 20, with
   gnome-shell-3.10.1-2
   gcr-3.10.0-1
   gnome-keyring-3.10.0-1

if any further update makes this "fallback" dialog dropped, then I agree, bad luck, though it would be too surprising to see gcr rely on custom implementations for each single desktop environment for gcr-prompt/er.
Comment 36 Florian Müllner 2014-02-04 19:48:30 UTC
Ah right, you found a hole in the logic - the keyring dialog has to be enabled at least once to start working like this. So looks like you are safe for the time being :-)
(Note however that in 3.12, you will no longer be able to edit the source file directly)
Comment 37 Kamil Páral 2014-02-05 12:12:37 UTC
(In reply to comment #33)
> To get more sane password prompts, as a workaround, edit your sessionMode.js (I
> have it at /usr/share/gnome-shell/js/ui/) and delete from there 'keyring'
> string from components of 'user' session (together with its corresponding
> comma) - there is only one such string. Then restart gnome-shell.

Milan, would you be willing to create a gnome-shell extension?
Comment 38 Milan Crha 2014-02-05 15:56:28 UTC
(In reply to comment #37)
> Milan, would you be willing to create a gnome-shell extension?

I do not code JavaScript, neither use gnome-shell, I'm sorry.
Comment 39 johannes.kingma 2014-02-13 20:46:19 UTC
The discuession is really intriguing

Did someone "solve" the from a usability point of view, quite harmful system modal password entrering dialog?

It is quite a show stopper for me.
Comment 40 Matijs van Zuijlen 2014-05-26 09:25:31 UTC
For me, these dialog boxes have started to pop up randomly (probably triggered by Empathy), so I cannot even prepare by copying the password beforehand.
Comment 41 André Klapper 2014-06-12 22:31:50 UTC
*** Bug 731588 has been marked as a duplicate of this bug. ***
Comment 42 alex 2014-06-15 15:10:26 UTC
design proposal:
make the password dialog to a notification popup wherein you can type(or copy) the password something like the empathy chat.

If the user opens the password dialog intentionally (e.g. connects to a new network), slide the passworddialog from the middle of the screen to the corner.
This should help newbies to find the new password dialog.
Comment 43 alex 2014-06-15 15:11:52 UTC
^newbies: beginners. Sorry wrong word
Comment 44 814ckf0x 814ck734m 2014-06-16 15:59:02 UTC
I really hate blocking-modal-dialog from the time it appeared in GNOME, because it has no use, has no sense. why implementing blocking-modal-dialogs?

According to GNOME Usability Project and having Heuristic Evaluation in mind, blocking-modal-dialog is simply a mistake:
- Is it obvious what's happening at each point?

Is it obvious to block the user session when asking him for a password? even when the user use an external application to store/generate/manage his password? Not only the session password, not only the GNOME apps passwords, even no only the internet/web user accounts passwords.

Seahorse is not designed to manage passwords, It is heavily designed to store passwords, to store gnome-compatible applications password, of course, you can store all kind of passwords you want, but it's not implement to easily use the password in non-gnome-compatible applications e.g by auto typing the password inside the application, or the web page, or whatever. And when Seahorse fails, when the application witch uses seahorse fails, and you need to introduce the password by your self... A blocking-modal-dialog comes to remember you that you can't even open Seahorse to copy your password.

- Is the system efficient to use?

There is no efficiency in canceling the password request, copying you password to the clip board, and trying to trigger the event witch requests the password (it takes not only 3 steps), some times you don't even know where the request comes from, or why.

- Is it visually attractive?

Well, as a modal dialog, it's attractive, it's clear and makes you focus on it. but when you realize that is blocking all your desktop until you click accept, or cancel, It becomes annoying.

As you can see, I'm talking about modal dialog focusing on its blocking attribute and in particular focusing on the modal password dialog. but I think its applicable to the whole of its uses.

At this point I realize that there is not interest from the gnome developers to change this issue, and always says: "Why don't you use keyring (Seahorse) to manage your passwords?" and I ask you: Why can't I decide if using keyring or use another password manager?, why can't I switch an option to make modals passwords non blocking?

I think this is not only my opinion, I think there are most people with the same problem... I hope this post makes you think about it...
Comment 45 johannes.kingma 2014-06-16 20:28:31 UTC
However entertaining this discussion is, it would be helpful if something helpful would come out of it.

Suggestions:
1) Why is the dialog modal? There is no reason for a password entry screen to be system modal, application modal yes, but system modal?
2) If other keyrings would be supported this would be swell. I have to switch between a Nix and a MS system frequently (as I need MS Office) so I use Keepass as keyring. 
3) Visually attractive? Pulease. it should work! first! than look at whatever look, blows you skirt. 

Less ideal:
4) Import existing keyrings (kdb(x)) into the keyring.
less as it will make a snapshot.

Btw the whole Evolution password thing is something else that should (it really should, guys, I mean, come on!) by the Evolution team and is related to gnome but nothing more than that.
Comment 46 johannes.kingma 2014-06-16 20:28:31 UTC
However entertaining this discussion is, it would be helpful if something helpful would come out of it.

Suggestions:
1) Why is the dialog modal? There is no reason for a password entry screen to be system modal, application modal yes, but system modal?
2) If other keyrings would be supported this would be swell. I have to switch between a Nix and a MS system frequently (as I need MS Office) so I use Keepass as keyring. 
3) Visually attractive? Pulease. it should work! first! than look at whatever look, blows you skirt. 

Less ideal:
4) Import existing keyrings (kdb(x)) into the keyring.
less as it will make a snapshot.

Btw the whole Evolution password thing is something else that should (it really should, guys, I mean, come on!) by the Evolution team and is related to gnome but nothing more than that.
Comment 47 van.de.bugger 2014-06-19 16:11:36 UTC
My Bug 708333 was closed as a duplicate of this one, like 8 other bugs. This one exists for 1.5 years for now. Is there any progress?

Blocking entire user session by system-wide modal dialog is obviously a mistake and should be fixed or, at least workarounded ASAP.
Comment 48 Milan Crha 2014-06-20 10:53:34 UTC
(In reply to comment #47)
> Blocking entire user session by system-wide modal dialog is obviously a mistake
> and should be fixed or, at least workarounded ASAP.

One workaround can be found at comment #33, but, if you keep reading, then it may not always be the right thing.
Comment 49 Florian Müllner 2014-07-03 08:56:00 UTC
*** Bug 732659 has been marked as a duplicate of this bug. ***
Comment 50 johannes.kingma 2014-07-08 23:01:01 UTC
I hate to be anal but this is a show stopper for me.

Again: if someone could explain compellingly what is the reason behind a system modal password dialog I'm happy to accept the facts of life. If not, why is it system modal. 

(There seem to be a number of users with the same problem, considering the number of duplicates. Solve this and solve at least a dozen-or-so problems. How's that for incentive?)
Comment 51 André Klapper 2014-07-31 21:09:39 UTC
*** Bug 734070 has been marked as a duplicate of this bug. ***
Comment 52 Allan Day 2014-08-04 17:02:51 UTC
There are a number reasons to use a modal dialog that I can think of:

1. To ensure that the user passes through a required step before proceeding further - imagine cases where an app is literally waiting for a password in order to do something.

2. So that important steps are not lost. This follows on from the previous point - if the dialog is floating, it could be placed behind other windows, even though it is blocking an app from doing something.

3. To make it clear what owns the dialog - this ensures that it is clear what is generating the dialog in the first place (in this case, it is the OS that is spawning the dialog), as well as what will use the information that is entered. This is particularly important with security information, since it makes you more feel more confident/secure if you are certain about where your password is going.

In these terms, we are doing better than in the GNOME 2 days.

With regards to this specific bug, having to close the dialog and try again doesn't seem terrible if it is a very infrequent event. The problem is when you have to battle it on a regular basis.

I can't help but think that there must be a solution out there, other than returning to the old floating-dialog-with-no-clear-owner model. Could we make Seahorse secure/featureful enough to store these passwords, perhaps with a way to select a stored password from the dialog? Perhaps there could be a way to slide the dialog out of the way, while keeping it partially in view?
Comment 53 Jasper St. Pierre (not reading bugmail) 2014-08-04 17:09:49 UTC
(In reply to comment #52)
> 3. To make it clear what owns the dialog - this ensures that it is clear what
> is generating the dialog in the first place (in this case, it is the OS that is
> spawning the dialog), as well as what will use the information that is entered.
> This is particularly important with security information, since it makes you
> more feel more confident/secure if you are certain about where your password is
> going.

We have three such modal dialogs.

* Network agent. This is for network secrets, like passwords, although there maybe others. This is validly part of the OS.

* Keyring agent. This is for arbitrary requests to the Secrets Service. Applications can make these requests.

* Polkit agent. This is for PolicyKit authentication requests. Applications can make these requests as well.

In two of the three cases, the password request is likely coming from an application, rather than the system. Unfortunately, we don't have enough context in either of these APIs to tell which application the request is coming from. It could be that with application sandboxing, we'll have a non-spoofable way of figuring out the application container and thus the correct .desktop file, so we can show the application in the prompt.

But don't think that the only valid case for these password dialogs to show up is by a request from the OS.
Comment 54 Adam Williamson 2014-08-04 17:18:39 UTC
Allan: we already did the 'I don't see the big deal' go round nearly two years ago, in the first dozen or so comments. Can we please skip doing that rodeo twice?

"Could we make Seahorse secure/featureful enough to store these passwords, perhaps with a way to select a stored password from the dialog?"

Not unless you're going to build and manage a hosted service backend for it (or at *least* give it support for some kind of remote sync protocol), no. Anyone who's used Lastpass or 1Password is never going to go back to non-synced password storage.

"3. To make it clear what owns the dialog - this ensures that it is clear what
is generating the dialog in the first place (in this case, it is the OS that is
spawning the dialog)"

I asked about that on IRC yesterday, and someone said that any running app can quite trivially cause Shell to generate such a dialog. It provides no security.

"I can't help but think that there must be a solution out there, other than returning to the old floating-dialog-with-no-clear-owner model."

It's certainly possible, it's just a question of whether someone wants to do the work. The thing to do would be to build integration with password managers in general in some way; I don't think you're going to get away with only integrating with Seahorse unless you make Seahorse *really* good.
Comment 55 Jürg Billeter 2014-08-04 17:22:26 UTC
(In reply to comment #53)
> In two of the three cases, the password request is likely coming from an
> application, rather than the system. Unfortunately, we don't have enough
> context in either of these APIs to tell which application the request is coming
> from. It could be that with application sandboxing, we'll have a non-spoofable
> way of figuring out the application container and thus the correct .desktop
> file, so we can show the application in the prompt.

Sandboxed applications should never be able to trigger system-modal dialogs. I don't like system-modal dialogs in general where not absolutely required (screen lock), however, for (sandboxed) applications I don't think it's even debatable. A malicious or buggy application could continuously trigger an authentication request and thus render the system unusable. Also, forced interruption when another application is active is already unacceptable.

Making the authentication dialog application-modal and showing a notification, if the application is inactive, makes a lot of sense to me.
Comment 56 Allan Day 2014-08-04 18:11:56 UTC
(In reply to comment #54)
> Allan: we already did the 'I don't see the big deal' go round nearly two years
> ago, in the first dozen or so comments. Can we please skip doing that rodeo
> twice?
...

Comment 46 asked for an explanation for the use of modal dialogs, which I provided. Give me a break.
Comment 57 André Klapper 2014-08-04 19:34:12 UTC
(In reply to comment #52)
> 1. To ensure that the user passes through a required step before proceeding
> further - imagine cases where an app is literally waiting for a password in
> order to do something.

In general, that makes sense if the dialog blocked the application's window, not necessarily if the dialog blocked my entire ability to switch to another window in my desktop environment.

But Jasper listed the valid situations in comment 53 when such dialogs are "gnome-shell-wide".
Comment 58 Byron Hawkins 2014-08-04 19:47:08 UTC
I quit using Evolution a year ago because the system-modal password dialog is worse than malware.
Comment 59 Jean-François Fortin Tam 2014-08-04 22:21:38 UTC
> 3. To make it clear what owns the dialog

AFAIK a normal transient+modal GTK dialog does exactly that; it is attached to the window and blocks the application, and the window in the background gets dimmed in quite an obvious way. Why not use that?

> 1. To ensure that the user passes through a required step before proceeding
> further - imagine cases where an app is literally waiting for a password in
> order to do something.

Applications can wait. Nobody's gonna die.

Wouldn't it be better to simply have your system (or GTK) call a gtk_window_set_urgency_hint() on those newly created app-modal password prompts, therefore triggering GNOME Shell to show up a notification saying "hey, this window needs your attention"? I think that would solve the problem.
Comment 60 Kamil Páral 2014-08-05 08:46:28 UTC
(In reply to comment #52)
> 1. To ensure that the user passes through a required step before proceeding
> further - imagine cases where an app is literally waiting for a password in
> order to do something.
> 
> 2. So that important steps are not lost. This follows on from the previous
> point - if the dialog is floating, it could be placed behind other windows,
> even though it is blocking an app from doing something.
> 
> 3. To make it clear what owns the dialog - this ensures that it is clear what
> is generating the dialog in the first place (in this case, it is the OS that is
> spawning the dialog), as well as what will use the information that is entered.
> This is particularly important with security information, since it makes you
> more feel more confident/secure if you are certain about where your password is
> going.

Alan, could you please elaborate why that is not ensured perfectly by application-modal dialogs, instead of system-modal dialogs?

Because application-modal dialogs have these benefits over system-modal ones:
1. They don't block you from using *any* password manager
2. They don't block your other tasks and break your workflow
3. They are more secure, because you clearly see what application requests the password. That is not the case for system-modal dialogs - someone on #fedora-desktop recently demonstrated to me and Adam that any process can spawn a system-modal dialog and there's no way to identify who its owner is.
4. They are less confusing, because those dialogs can't pop out of nowhere, like in bug 709430 (it's not fixed, appeared again in bug 697668#6).

So, these are the benefits and I don't see any drawbacks. Why exactly does GNOME prefer system-modal to application-modal? I believe this is the major question. I'm sorry if I have overlooked the answer somewhere among all the comments.
Comment 61 Florian Müllner 2014-08-05 09:38:07 UTC
(In reply to comment #60)
> Alan, could you please elaborate why that is not ensured perfectly by
> application-modal dialogs, instead of system-modal dialogs?

System-modal dialogs would work a lot better if we only allowed them for the focused app, but unfortunately we cannot know reliably which application requested the dialog. That problem does not magically go away by not using system-modal dialogs - application-modal dialogs are not an option if we don't know the application in the first place. As things stand right now, the only alternative are GNOME2-style dialogs not associated with any application, which have exactly the problems pointed out by Allan in comment #52.
Comment 62 Kamil Páral 2014-08-05 10:39:33 UTC
> application-modal dialogs are not an option if we don't
> know the application in the first place.

Can you please expand this? I thought that application-modal dialogs are fully controlled by the applications themselves, therefore no intervention by GNOME is needed. So Evolution and similar GNOME apps could be patched to use application-modal dialogs instead of system-modal, and manually request focus in case they are not currently focused. That (focus requesting) would most probably work just for those applications which implemented it this way, not in general. Is this your point, would you like to somehow detect application-modal dialogs in GNOME Shell and request focus for them automatically? Or would you like to modify all application-modal dialogs' appearance to look like "shell dialogs", and that's not currently possible to achieve? Or was the point something completely different? Thanks for clarification.
Comment 63 Lukas Pirl 2014-08-05 10:48:59 UTC
(In reply to comment #60)

> So, these are the benefits and I don't see any drawbacks.

+1! Personally - I don't see any valid use case (on my desktop) for system-modal dialogs. No application (even not the highly integrated ones like the network manager) should ever block the whole desktop. (But this is an interesting discussion since apparently there are users that like those dialogs…)
Comment 64 Matijs van Zuijlen 2014-08-05 10:52:27 UTC
(In reply to comment #62)
> > application-modal dialogs are not an option if we don't
> > know the application in the first place.
> 
> Can you please expand this? I thought that application-modal dialogs are fully
> controlled by the applications themselves, therefore no intervention by GNOME
> is needed. So Evolution and similar GNOME apps could be patched to use
> application-modal dialogs instead of system-modal, and manually request focus
> in case they are not currently focused. That (focus requesting) would most
> probably work just for those applications which implemented it this way, not in
> general. Is this your point, would you like to somehow detect application-modal
> dialogs in GNOME Shell and request focus for them automatically? Or would you
> like to modify all application-modal dialogs' appearance to look like "shell
> dialogs", and that's not currently possible to achieve? Or was the point
> something completely different? Thanks for clarification.

As I understand it, the system model dialogs pop up if an application needs a system service that requires a password. To take the evolution case as an example, it can use accounts managed by gnome-online-accounts. If it tries to access such an account, it is gnome-online-accounts that wants the user to enter a password. Evolution has no knowledge of this. The same is true for the three cases mentioned in comment #53. There, it is the agent that decides to show a dialog (or not if it is not needed).
Comment 65 Florian Müllner 2014-08-05 10:59:13 UTC
(In reply to comment #62)
> > application-modal dialogs are not an option if we don't
> > know the application in the first place.
> 
> Can you please expand this? I thought that application-modal dialogs are fully
> controlled by the applications themselves

Yes. But the dialogs in question are not opened directly by applications, but by gnome-keyring-daemon and polkitd in response to some DBus requests. We don't have any reliable way to map a DBus address to an application/window, so all we really know is "something asked gnome-keyring-daemon/polkitd for a password/authentification". The fact that in some cases the actual request is not done by any application, but by another background service (evolution-data-server) doesn't make it any easier ...
Comment 66 Matijs van Zuijlen 2014-08-05 10:59:41 UTC
(In reply to comment #52)
> Perhaps there could be a way to
> slide the dialog out of the way, while keeping it partially in view?

This sounds like an excellent idea.
Comment 67 Allan Day 2014-08-06 11:58:45 UTC
I had a chat with Stef Walters today about which systems are generating the dialogs, and what the plan is for the future. According to Stef, there are four places where these dialogs come from:

 1. Network Manager - for wifi/VPN passwords, etc.
 2. Polkit - for admin/user passwords to unlock permissions.
 3. GNOME Keyring - for unlocking GPG/SSH keys (according to Stef, the keyring doesn't actually throw up generic password dialogs).
 4. Gcr - used by Evolution Data Server and GOA-agent to ask for passwords. [1]

Stef agrees that shared application passwords don't make sense for sandboxed applications, and there's a plan to enable applications to securely store their own passwords [2] (this needs a developer though). Being able to have passwords encrypted on disk might well help with some of these cases.

According to my understanding, 1-3 are system password prompts:

 1. It's the OS that handles your networking. It's the OS that needs your password.
 2. The OS is guarding access to a restricted ability, and it needs to confirm your identity.
 3. The OS is guarding access to your keys, and needs the password to unlock them on a system-wide basis.

4 is a bit different. You could argue that both Evolution Data Server and GOA are OS subsystems, and are therefore appropriate to use a system modal dialog. However, it really depends on how these dialogs are being used - a modal dialog of any kind should never pop up unexpectedly. I'm rather sceptical about the need for EDS or GOA to use these password dialogs.

Stef also suggested the possibility of re-examining 3. The GPG and SSH agents need some reworking anyway, apparently.

I realise that this information doesn't necessary identify a fix for the bug - just wanted to post my research so far.

[1] https://developer.gnome.org/gcr/unstable/GcrSystemPrompt.html#

[2] http://www.superlectures.com/guadec2013/more-secure-with-less-security [from slide 37]
Comment 68 Adam Williamson 2014-08-06 12:17:03 UTC
FWIW, case #3 is the one I run into all the time that makes me want to throw my laptop through a window.
Comment 69 Jasper St. Pierre (not reading bugmail) 2014-08-06 12:28:30 UTC
What if your Wi-Fi password is in a password manager? Or, as I encountered at GUADEC, in an email I received? Cancelling and restarting was a bit annoying.
Comment 70 alex 2014-08-06 12:50:47 UTC
I would propose a new widget for gtk+, an authorisation dialog and a state bit in all gtk+ widgets signaling if the are running with root rights (to disable dangerous functionality, like preview of pictures with root rights; also for not polluting the root home folder with config files).

The authorisation dialog should lock up only the associated window and only if in the keyring is a wrong or no password.
Also it should show the reason why it is shown (e.g. wrong password, no password in keyring, no response) and for what functionality it is shown (set by the application itself)

disadvantage: how should menu entries be handled?
Comment 71 Allan Day 2014-08-06 12:53:55 UTC
Going through the dupes for this bug, to see what is causing the most annoyance:

Bug 689663 - not actually a shell issue?
Bug 689663 - not clear. Possibly GOA?
Bug 688295 - GPG (therefore GNOME keyring).
Bug 700057 - seems to be a spontaneous request, probably Evolution Data Server.
Bug 708333 - Evolution.
Bug 709513 - Evolution/EDS.
Bug 731588 - EDS.
Bug 708333 - EDS.
Bug 734070 - GParted (probably a Polkit request).
Comment 72 Adam Williamson 2014-08-06 13:14:17 UTC
I suspect the numbers are somewhat skewed in 'favour' of Evolution by the bug that seems to cause it to forget/lose the authentication for Google accounts periodically, FWIW.
Comment 73 Jeremy Nickurak 2014-08-06 17:06:19 UTC
Another case: The system is looking for a passphrase to unlock a ring/private-key. (Keyrings and ssh keys both apply here). The passphrase required is stored in a password manager. You must be able to unfocus the system-modal prompt in order to access the password manager, in order to satisfy what the system-modal prompt is looking for. Seems to me that's a pretty standard deadlock issue, except in UI multitasking instead of multi-threaded application programming.
Comment 74 Allan Day 2014-08-07 11:27:23 UTC
I've been looking into the possibility of using a GTK+ dialog for SSH/GPG passphrase requests, but it seems difficult/impossible to make such dialogs modal to the window that made the request. Any ideas here would be welcome.
Comment 75 Florian Müllner 2014-08-07 11:35:15 UTC
(In reply to comment #74)
> I've been looking into the possibility of using a GTK+ dialog for SSH/GPG
> passphrase requests, but it seems difficult/impossible to make such dialogs
> modal to the window that made the request.

If there even is a window - in case of GPG, the request could come from a CLI utility running in some terminal (or even the alt-f2 run dialog) ...
Comment 76 Kamil Páral 2014-08-11 11:44:15 UTC
Would it make sense to convert all system-modal dialogs to notification bubbles sliding up from the bottom edge? There would be a text field asking for the password. I believe this approach used to be in place when you connected an encrypted external drive, but I'm not sure whether it's still used or not.

As for EDS and GOA background processes, it seems to me that the least confusing approach would be to spawn a system notification saying "Your Google password is invalid [Fix password]" which would open Evolution/GOA configuration dialog where you would provide the password the usual way. Which seems to be along the lines of what Allan says, IIUIC - the system password dialogs should never appear out of the blue, but rather you should be notified that something is wrong and you should be directed to the correct place to fix it. Therefore you would know which password you're giving (with Google's application passwords, you can have different passwords for different applications) to which application (you see it in front of you) and why.
Comment 77 Florian Müllner 2014-10-09 14:04:07 UTC
*** Bug 738232 has been marked as a duplicate of this bug. ***
Comment 78 Johannes Rohr 2014-10-09 14:23:23 UTC
(In reply to comment #77)
> *** Bug 738232 has been marked as a duplicate of this bug. ***

My bug report was not only complaining about the modal dialogue, it was also noting that the dialogue provides no information about which application is requesting the password and for which account. As I wrote in my report, the only hint the prompt provides is the e-mail address associated with the account, but in my case I count about five different accounts with whom my e-mail is associated, so it is total guesswork which password I am supposed to enter.
(BTW: I think that ultimately gnome-shell was asking for my facebook password, but since something about facebook and G-O-A is b0rken, see bug #738109, even entering the correct password did not help, so I could enter passwords all day and not get the slightest hint or idea what is causing all these prompts and what to do about them. This really needs to be settled.
Comment 79 Ulrich Keller 2014-11-03 11:37:21 UTC
I had three of these pop up during a presentation, it was rather embarrassing. Two came from GOA (I think), one from NetworkManager. Kamil Páral's suggestion in #76 would be a huge improvement (even if all the related problems remained unfixed).
Comment 80 Bastien Nocera 2014-11-07 09:28:21 UTC
Marking as a duplicate of the older bug 660293.

The "Evolution makes Google accounts pop up passwords" problem was fixed in bug 735311.

*** This bug has been marked as a duplicate of bug 660293 ***
Comment 81 Ulrich Keller 2014-11-07 12:32:37 UTC
(In reply to comment #80)
> The "Evolution makes Google accounts pop up passwords" problem was fixed in bug
> 735311.

I'm running evolution-data-server 3.12.7.1 and I still get several of these popups per day.
Comment 82 Paul Smith 2014-11-07 15:02:44 UTC
I really don't like that this bug was marked as a duplicate and closed.  This bug actually has some useful information, use-case examples proving the problem is serious, and even suggestions about improvements.

But 660293 is a wasteland of shrugs and "oh well nothing to be done".  Plus, that bug is specifically about NetworkManager, which is a relatively straightforward case, while this bug is about all sorts of modal password prompts.

Personally I don't care at all about NetworkManager, my problem is Evolution.  It wants to get passwords to my email accounts and calendars, and it asks for these passwords when it tries to connect to the remote accounts which happens completely asynchronously.  Of course, all my accounts use randomized, long passwords.  Basically there's no way for me to get my password when Evolution asks me for it, so I just have to hit cancel.  I've not been able to connect to my calendar for months and months because of this.

If anything, I think bug 660293 should be closed as a duplicate of THIS bug.
Comment 83 Ulrich Keller 2014-12-05 12:46:35 UTC
It's sad that there seems to be no interest in solving this problem. "Distraction-free computing", remember? The multiple system-modal dialogs I had to deal with every day were the most distracting and intrusive thing I've ever encountered in a DE.

My first workaround was to quit using Evolution and disable all online accounts. Then I realized that these were really the main reason I'd still been using Gnome in the first place. So my current workaround is to use Cinnamon and Thunderbird instead. So long.
Comment 84 Adam Williamson 2015-01-22 23:28:52 UTC
As several reporters suggested, I'm un-duping this. I explicitly acknowledged 660293 and explained why I was filing a new bug when reporting this:

"This is similar to https://bugzilla.gnome.org/show_bug.cgi?id=660293 , but it's
the general case - this can happen with _any_ case of the Shell password entry
dialog, it's not limited to that specific NM case."

#660293 is still set as a report specific to NM.
Comment 85 Milan Crha 2015-02-02 16:38:25 UTC
(In reply to comment #82)
> ... my problem is Evolution. 
> It wants to get passwords to my email accounts and calendars, and it asks for
> these passwords when it tries to connect to the remote accounts which happens
> completely asynchronously.  Of course, all my accounts use randomized, long
> passwords.  Basically there's no way for me to get my password when Evolution
> asks me for it, so I just have to hit cancel.  I've not been able to connect to
> my calendar for months and months because of this.
> ...

Fixed for evolution 3.13.90, more info at [1].

[1] https://mail.gnome.org/archives/evolution-hackers/2015-February/msg00000.html
Comment 86 Matthias Clasen 2015-03-06 13:04:20 UTC
moving off the tracker
Comment 87 Milan Crha 2015-04-28 15:25:50 UTC
*** Bug 708333 has been marked as a duplicate of this bug. ***
Comment 88 Florian Müllner 2015-06-30 07:52:05 UTC
*** Bug 743763 has been marked as a duplicate of this bug. ***
Comment 89 Audrey Toskin 2015-11-09 05:52:40 UTC
(In reply to Milan Crha from comment #85)
> (In reply to comment #82)
> > ... my problem is Evolution. 
> 
> Fixed for evolution 3.13.90, more info at
> https://mail.gnome.org/archives/evolution-hackers/2015-February/msg00000.html

Modal password boxes preventing users from looking up passwords isn't just a problem for Evolution, though. Try connecting to an SFTP account in Nautilus -- it's the same situation. The bugs which have been marked as duplicates of this one touch on various applications, but they share a problem with the the modal password popup.

And this is still a problem in GNOME 3.18.
Comment 90 Florian Müllner 2016-02-23 09:55:35 UTC
*** Bug 741989 has been marked as a duplicate of this bug. ***
Comment 91 c1412830 2016-05-07 14:08:29 UTC
Hi, I have the same problem, but worse. Not only does the SSH password prompt prevent me from using my password manager, but it also *prevents me from pasting*. This means that even if I copy my password before getting the password prompt, I can't use it. AT ALL.

Even if you consider the original problem of this bug as a minor inconvenience (which it is not), this is a real blocking bug that prevents users from using password managers, and forces them to use the antiquated strategy of remembering all their passwords, which leads to significantly weaker security.

Given that using a password manager to improve security is more and more recommended, the fact that this bug is still open after ALMOST FOUR YEARS is just ridiculous. Put this prompt in a notification, so that this no more annoys users while you're thinking of a better solution.
Comment 92 Adam Williamson 2016-05-08 16:13:22 UTC
That's a different bug. Are you using Wayland? https://bugzilla.gnome.org/show_bug.cgi?id=758958
Comment 93 Christian Stadelmann 2017-02-11 21:45:51 UTC
How about making the password box always on top, but still have it possible to focus different applications?
Comment 94 GNOME Infrastructure Team 2021-07-05 14:46:36 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.