Explaining per kgunn's request: What we have currently is: whatever initiates a trusted session provides a PID of the process it wants to open the prompt on. The problem there is that trusted helpers need not necessarily know what that PID should be, because the request might come from a scope, which has no UI. Currently the helpers just cheat by going `pidof unity8-dash` and open the session with that.
In the general case it's fine because apps interact with trusted helpers directly, so the helpers can identify the connecting PID (with the exception that upcoming multi-surface support will somewhat break this, as the helper has no way to uniquely identify the surface to relate the session to). What we need is for the trusted "broker", that scope-registry is, to be able to create a non-spoofable relation between whatever surface displays the data for a particular scope, and pass it down to the scope, which will then pass it to trusted helpers. The exact solution is not clear yet. In addition, somewhat off-topic, we want to add an optional "type" and "metadata" or "geometry" arguments for a trusted prompt, to allow per- type transitions (immediate use case - media player as trusted prompt should grow from a thumbnail to fullscreen). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1352251 Title: Reverse trust prompt hosting Status in Qt integration with the Mir display server: Triaged Status in unity8 package in Ubuntu: Triaged Status in unity8 package in Ubuntu RTM: Triaged Bug description: In order to keep continuity, keeping this original bug rather than spawning a new one. new description: currently non ui process are asking for trust prompts from related focused ui's, example scopes ask for dash to host a prompt. however, it needs to be the other way around, with the ui process having a list of pid's that it can host for. original description: On the phone, a splash screen is shown as soon as QGuiApplication is instantiated; however, a QWindow might be created much later, or not be created at all. We have for example a D-Bus service (ubuntu-system-settings-online-accounts) which is a QGuiApplication, but creates QWindows only as client requests arrive. In the common case, this works fine because the service is generally started when a window needs to be displayed, but we are now preparing for implementing trust session support, and that would require either this bug to be fixed, or a deeper refactoring of our code. see below, that the original description was simply incorrectly using the default socket, instead of the trust socket. the default socket causes the splash screen, whereas the trust socket won't To manage notifications about this bug go to: https://bugs.launchpad.net/qtmir/+bug/1352251/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
