Make click apps runnable from the Unity7 dash
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
- Started by
- Completed by
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