Make click apps runnable from the Unity7 dash

Registered by Daniel Holbach on 2013-11-05

Meeting agenda and possible work items to think about:
- Flesh out security warning with Security team.
- Discuss implementation details with Unity7+Security teams.
- Track implementation.
- Announce availability.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Daniel Holbach
Direction:
Approved
Assignee:
None
Definition:
New
Series goal:
Accepted for trusty
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Notes:
 - concerns:
    no way to confine when running under X - trivial to bypass confinement
    opens up a great target for possible malware in click packages
 - packages come from store: people trust us, expect security
    if we run into security issues, the security story for us is going to be really bad

 - possible options:
   - modify aa-exec-click to issue warning and/or people would have to
     provide '--insecure'
     - warn, bail out, maybe mention a wiki page with an faq
   - click exec hook could modify exec command
     - run under nested X server
       - requires work
       - footprint bigger
       - but we have isolation
       - would likely break global menu and stuff
       - Jamie has some code available, but can't commit the Security
         team to do all the work
       - might be worth investigating
       - 3d might not work
     - we could modify .desktop files to not be shown in unity7
     jdstrand> I evaluated starting a nested xserver (Xpra and Xephyr) and it just isn't viable without significant engineering effor. It kinda works, but Xpra is quite flaky and xephyr needs updates but the user experience is not great.

 - present situtation:
   - install .click, findable on dash, started under confinement (minus X issues)
   - if you install under unity8, you install under unity7 as well -
   - if you have click scope installed, you can install click packages already
   - webapps are less of an issue, but there's another session about it

 - implementation of installation:
   - packagekit and aptdaemon provide the same D-Bus interface and thus do not coexist
   - aptdaemon used on the desktop to provide better support for interactivity during
     install (e.g. debconf questions)
   - simplest path is probably to figure out how to plug click into aptdaemon in
     much the same way that we do with packagekit, to decouple this from any future
     switch of the desktop to packagekit
   - however, perhaps we ought to not do the same permission tweak that we do
     on touch which arranges for users not to need administrative permissions to
     install click packages

 - open questions:
   - when is the alternative unity8 desktop session going to land?
     ask somebody on Jason's team
     "some time have something by 14.04"

(?)

Work Items

Work items for ubuntu-13.11:
[dholbach] file a bug to get the SDK to install the .click locally and run it locally (bug 1255521): DONE

Work items for ubuntu-13.12:
[dholbach] find out for when unity8 desktop session is scheduled: INPROGRESS
[dholbach] write FAQ about security implications, how to use emulator, etc.: TODO

Work items:
[dholbach] help with announce of unity8 desktop session when available: TODO
[jdstrand] investigate if nested xservers could be used for click apps under unity7: DONE
[cjwatson] implement click support for aptdaemon: TODO
[jdstrand] modify aa-exec-click to warn and bail out on non-Mir: DONE
[jdstrand] add -x switch to force launch under X and document in manpage: DONE
[cjwatson] move fast-path queries out to a libclick accessible from C code: DONE