Created attachment 236993 [details]
screenshot

That's coming from Evolution-Data-Server, because GNOME Shell is trying to access your Google calendar.  You initiated the action by logging in.

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

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

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

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

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

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

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.

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.

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

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

Adding as a 3.16 target - this is an annoying bug which doesn't make us look very good.

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