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.

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.

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.

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.

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.

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.

*** Bug 686531 has been marked as a duplicate of this bug. ***

*** Bug 689663 has been marked as a duplicate of this bug. ***

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.

jeremy: damn you, give me back my ragecomic summary! :)

I appreciated the sentiment... but searching bugzilla is bad enough without joke titles. (which is why I filed a dupe...)

(In reply to comment #10)
> jeremy: damn you, give me back my ragecomic summary! :)

We all have to make sacrifices sometimes...

*** Bug 688295 has been marked as a duplicate of this bug. ***

Any workarounds available? Any way to make it non-modal, temporarily or
otherwise?

my workaround is still "swear, smack the desk, hit Esc, copy the password, then do it again", sadly.

*** Bug 700057 has been marked as a duplicate of this bug. ***

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.

*** Bug 700930 has been marked as a duplicate of this bug. ***

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

and there should be a possibility to push it back in the notification area

*** Bug 704674 has been marked as a duplicate of this bug. ***

+1, to which I'd add, for the specific case of wifi network passwords, that they should not be obfuscated (bug #667370).

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

*** Bug 708333 has been marked as a duplicate of this bug. ***

*** Bug 709513 has been marked as a duplicate of this bug. ***

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.

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.

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

(In reply to comment #28)
> Please file a bug against Evolution.

Bug 709513 is marked as a dup of this one.

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

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.

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

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.

(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').

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

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)

(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?

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

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.

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.

*** Bug 731588 has been marked as a duplicate of this bug. ***

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.

^newbies: beginners. Sorry wrong word

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

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.

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.

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.

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

*** Bug 732659 has been marked as a duplicate of this bug. ***

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?)

*** Bug 734070 has been marked as a duplicate of this bug. ***

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?

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

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.

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

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

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

I quit using Evolution a year ago because the system-modal password dialog is worse than malware.

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

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

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

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

(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…)

(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).

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

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

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]

FWIW, case #3 is the one I run into all the time that makes me want to throw my laptop through a window.

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.

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?

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

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.

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.

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.

(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) ...

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.

*** Bug 738232 has been marked as a duplicate of this bug. ***

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

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

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 ***

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

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.

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.

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.

(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

moving off the tracker

*** Bug 708333 has been marked as a duplicate of this bug. ***

*** Bug 743763 has been marked as a duplicate of this bug. ***

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

*** Bug 741989 has been marked as a duplicate of this bug. ***

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.

That's a different bug. Are you using Wayland? https://bugzilla.gnome.org/show_bug.cgi?id=758958

How about making the password box always on top, but still have it possible to focus different applications?

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.