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 694322 - Giant GTK warning when connecting to network
Giant GTK warning when connecting to network
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Shell
3.8.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
3.8?
: 734226 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-02-20 23:30 UTC by Cosimo Cecchi
Modified: 2015-02-02 16:29 UTC
See Also:
GNOME target: 3.16
GNOME version: ---


Attachments
screenshot (424.44 KB, image/png)
2013-02-20 23:31 UTC, Cosimo Cecchi
Details

Description Cosimo Cecchi 2013-02-20 23:30:52 UTC
I connected to a wireless network with a captive portal in a coffee shop. As soon as it connected, I got this huge GTK dialog from Evolution asking me to verify the calendar server certificate (which was coming from the captive portal in the middle instead). See attached screenshot.

Various bugs here I think:
- at a higher level, a backend component should never pop up system prompts like that for actions which were not initiated by the user inside an application using the backend
- if there's really a need for a system prompt, it should not be a GTK dialog, but a Shell one, and be presented at the time when it's needed for an user initiated action to complete
- "evolution-user-prompter" should never be used as an user-visible string
- the dialog in itself is quite obtrusive all in bold, but I think we should get rid of it entirely
Comment 1 Cosimo Cecchi 2013-02-20 23:31:09 UTC
Created attachment 236993 [details]
screenshot
Comment 2 Matthew Barnes 2013-02-20 23:58:29 UTC
That's coming from Evolution-Data-Server, because GNOME Shell is trying to access your Google calendar.  You initiated the action by logging in.
Comment 3 Cosimo Cecchi 2013-02-21 00:11:41 UTC
(In reply to comment #2)
> That's coming from Evolution-Data-Server, because GNOME Shell is trying to
> access your Google calendar.  You initiated the action by logging in.

I didn't initiate any action related to the calendar, nor logged in the session at that time, I only connected to a public network hotspot.
Comment 4 Milan Crha 2013-02-21 12:10:32 UTC
(In reply to comment #0)
> Various bugs here I think:
> - at a higher level, a backend component should never pop up system prompts
> like that for actions which were not initiated by the user inside an
> application using the backend

Well, either each and every client will provide required functionality for password prompts, and backend prompts (they are needed), or there will be some central place for these. We've one for password (evolution-source-registry) and one for backend prompts (evolution-user-prompter) now. As Matthew said, either this is when gnome-shell's calendar server stepped in, or evolution-alarm-notify. If you do not want it, then set the alarm notify to not run on session start. How about gnome-shell I do not know.

> - if there's really a need for a system prompt, it should not be a GTK dialog,
> but a Shell one, and be presented at the time when it's needed for an user
> initiated action to complete

I do not agree on this too, you are using gnome-shell, others are using Xfce, others KDE, others... and the only common thing is gtk3, to which eds/evo already depends.

> - "evolution-user-prompter" should never be used as an user-visible string

It's gnome-shell's invention, file a bug against them.

> - the dialog in itself is quite obtrusive all in bold, but I think we should
> get rid of it entirely

No, it's not all in bold, it tries to highlight important information in it. And we are not going to get rid of it for sure, it was just added to properly (and centrally) deal with SSL certificate prompts. If there are any design issues, aka how it looks like, then it can be discussed, yes, but otherwise this is for security purposes, and in your coffee shop usecase I'd say to deny it, because they pretend to be google server (or their proxy does, whatever).

This is not a bug, from my point of view.
Comment 5 Cosimo Cecchi 2013-02-21 13:35:24 UTC
(In reply to comment #4)

> Well, either each and every client will provide required functionality for
> password prompts, and backend prompts (they are needed), or there will be some
> central place for these. We've one for password (evolution-source-registry) and
> one for backend prompts (evolution-user-prompter) now. As Matthew said, either
> this is when gnome-shell's calendar server stepped in, or
> evolution-alarm-notify. If you do not want it, then set the alarm notify to not
> run on session start. How about gnome-shell I do not know.

I think backends should simply never prompt, otherwise they're not backends :)
I can understand why a backend component couldn't complete an action because of something that might require a user decision, but that doesn't mean it should prompt immediately, or itself.
In this specific case for example, I think it would be better to some sort of indication in the shell calendar dropdown if it can't refresh the list of events because of the SSL certificate error, which would bring you to Evolution (which could then display all the dialogs it wants) when clicked.

> I do not agree on this too, you are using gnome-shell, others are using Xfce,
> others KDE, others... and the only common thing is gtk3, to which eds/evo
> already depends.

As I said, I don't think there's any reason for this specific dialog to be a system prompt.

It's totally possible though to implement shell prompts falling back to GTK dialogs if the shell is not available. Many other components (gvfs, gnome-keyring, network-manager, polkit) are using it, possibly including some other areas of Evolution itself, as I'm pretty sure I've seen system modals related to it in the past.

> > - "evolution-user-prompter" should never be used as an user-visible string
> 
> It's gnome-shell's invention, file a bug against them.

The string seems to come from evolution-data-server. Which part of it do you think it's a shell bug?

> No, it's not all in bold, it tries to highlight important information in it.
> And we are not going to get rid of it for sure, it was just added to properly
> (and centrally) deal with SSL certificate prompts. If there are any design
> issues, aka how it looks like, then it can be discussed, yes, but otherwise
> this is for security purposes, and in your coffee shop usecase I'd say to deny
> it, because they pretend to be google server (or their proxy does, whatever).

Explaining the concept of SSL certificate security to users is hard (see e.g. what browsers do in a similar situation nowadays). But security cannot be used as an excuse to slap a giant dialog full of technical jargon out of the blue in front of people connecting to wireless :)

I could see a number of UI issues with the dialog itself, but I'd rather focus this bug to create a better experience that eliminates the dialog entirely in this situation.

To further clarify my previous sentence: it would be perfectly fine if this or a similar dialog was visible inside Evolution after it's started, and then we could think of ways to make it prettier.

> This is not a bug, from my point of view.

Please, reconsider this position. We made a lot of efforts in the last couple of years to keep the session clean from modal dialogs popping out of the blue, and to logically and visually separate system and application prompts.
Comment 6 Milan Crha 2013-02-28 08:16:20 UTC
(In reply to comment #5)
> I think backends should simply never prompt, otherwise they're not backends :)
> I can understand why a backend component couldn't complete an action because of
> something that might require a user decision, but that doesn't mean it should
> prompt immediately, or itself.
> In this specific case for example, I think it would be better to some sort of
> indication in the shell calendar dropdown if it can't refresh the list of
> events because of the SSL certificate error, which would bring you to Evolution
> (which could then display all the dialogs it wants) when clicked.

Having evolution as a hard dependency of evolution-data-server doesn't sound right. Remember, multiple applications can access sources configured in eds.

> As I said, I don't think there's any reason for this specific dialog to be a
> system prompt.

As far as I can tell, this dialog is not a system modal, you can do anything you want when it's shown, not like evolution password prompts, which don't let you do anything in the UI when shown (they use gcr, and multiple users expressed their disappointments on this decision).

> The string seems to come from evolution-data-server. Which part of it do you
> think it's a shell bug?

The string is a binary name, I believe. Bug in gnome-shell, from my point of view, is to show binary name, instead of window title. From eds root dir:
   $ git grep evolution-source-registry | wc -l
   314
   $ git grep Evolution-source-registry | wc -l
   0

> Please, reconsider this position. We made a lot of efforts in the last couple
> of years to keep the session clean from modal dialogs popping out of the blue,
> and to logically and visually separate system and application prompts.

As I mentioned above, this correlates with evolution password prompts being shown from nowhere after start, same as key ring password prompts and such.
Comment 7 Milan Bouchet-Valat 2013-03-10 10:34:31 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I think backends should simply never prompt, otherwise they're not backends :)
> > I can understand why a backend component couldn't complete an action because of
> > something that might require a user decision, but that doesn't mean it should
> > prompt immediately, or itself.
> > In this specific case for example, I think it would be better to some sort of
> > indication in the shell calendar dropdown if it can't refresh the list of
> > events because of the SSL certificate error, which would bring you to Evolution
> > (which could then display all the dialogs it wants) when clicked.
> 
> Having evolution as a hard dependency of evolution-data-server doesn't sound
> right. Remember, multiple applications can access sources configured in eds.
At least, what could be done is that the dialog itself is created by the backend, but applications have to call a function to show it when they think it is relevant. Thus, the calendar would detect an error has occured, but not show the dialog, and instead add a warning to the calendar view. The dialog would appear only when clicking on some button (or that button could start Evolution in calendar mode, and Evo itself would detect there's an error and show the dialog).

This way, applications could still use the dialog easily if they need it, but their developers would be forced to think better of when the dialog should pop up.

> > As I said, I don't think there's any reason for this specific dialog to be a
> > system prompt.
> 
> As far as I can tell, this dialog is not a system modal, you can do anything
> you want when it's shown, not like evolution password prompts, which don't let
> you do anything in the UI when shown (they use gcr, and multiple users
> expressed their disappointments on this decision).
> 
> > The string seems to come from evolution-data-server. Which part of it do you
> > think it's a shell bug?
> 
> The string is a binary name, I believe. Bug in gnome-shell, from my point of
> view, is to show binary name, instead of window title. From eds root dir:
>    $ git grep evolution-source-registry | wc -l
>    314
>    $ git grep Evolution-source-registry | wc -l
>    0
Yeah, the Application menu is named after the application, not after the window title. If think this string can be fixed by shipping a evolution-user-prompter.desktop file with a correct name (e.g. "Evolution") and Hidden=true.

> > Please, reconsider this position. We made a lot of efforts in the last couple
> > of years to keep the session clean from modal dialogs popping out of the blue,
> > and to logically and visually separate system and application prompts.
> 
> As I mentioned above, this correlates with evolution password prompts being
> shown from nowhere after start, same as key ring password prompts and such.
Yes, this is precisely the kind of lame situation we want to avoid. ;-)
Comment 8 Milan Crha 2013-03-21 18:51:45 UTC
I opened a thread for a discussion about this on evolution-hackers list, I only missed few people to CC on that. I'll appreciate if you could step in and give your opinions there. Thanks in advance.

[1] https://mail.gnome.org/archives/evolution-hackers/2013-March/msg00015.html
Comment 9 Stef Walter 2013-03-28 17:38:30 UTC
So this is *exactly* the reason why we should get away from putting up these accept/reject certificate prompts. 

Cosimo's connection is being highjacked (albeit by a captive portal) and the connection is not going through to the expected peer. And yet we throw up a prompt which most users would click through to void the security guarantees of SSL all together.

The choice to associate an non-standard certificate with a given connection should happen during connection setup. It should never happen on the fly. We should not follow the queue of web browsers in this arena. 

Application using a configured connections or accounts, which wishes to support use of non-standard (self-signed or otherwise) certificates with them, should implement a configuration option which allows association of the certificate with the account at the time that the account is setup.

The connection should just fail when an invalid certificate (and one not configured during account setup, if the application supports such an option) is presented by the remote SSL server.
Comment 10 David Woodhouse 2013-05-30 09:06:00 UTC
Well, we should also bear in mind that there's a NetworkManager bug here. It shouldn't be telling us that the connection is online, when it blatantly isn't. It should handle the login to the online portal first.

That isn't a panacea, of course, but it solves a large part of the immediate problem.

If I *am* connected properly to a network and my connections are *still* being hijacked, I probably don't mind being told about it even if it *isn't* a connection that I have explicitly triggered.
Comment 11 Milan Crha 2013-07-19 12:33:28 UTC
*** Bug 703168 has been marked as a duplicate of this bug. ***
Comment 12 Milan Crha 2014-11-28 11:24:21 UTC
*** Bug 734226 has been marked as a duplicate of this bug. ***
Comment 13 Allan Day 2014-12-01 11:48:51 UTC
Adding as a 3.16 target - this is an annoying bug which doesn't make us look very good.
Comment 14 Milan Crha 2015-02-02 16:29:10 UTC
I fixed this for 3.13.90 of evolution-data-server and evolution, see [1] for more information.

[1] https://mail.gnome.org/archives/evolution-hackers/2015-February/msg00000.html