Fwd: [Plash] Re: Zero-install and Plash

[Mark Seaborn]

Subject: Re: Zero-install and Plash
From: Mark Seaborn <address@hidden>
To: address@hidden
Date: Mon, 17 Jul 2006 20:54:22 +0100 (BST)

"Thomas Leonard" <address@hidden> wrote:

> On 7/16/06, Mark Seaborn <address@hidden> wrote:
> 
> Hi Mark,
> 
> > What do you think would be necessary to get zero-install to run
> > programs under Plash?  This is something I have been interested in
> > doing since I found out about zero-install when somebody mentioned it
> > on the cap-talk mailing list.
> 
> It's possible to do it manually already, but using 'download-only'
> followed by 'offline' mode:
> 
> plash$ !!0launch --download-only URI
> plash$ 0launch --offline URI ARGUMENTS + ~/.cache/0install.net
>
> (read access to ~/.cache/0install.net could be added to the default 
> environment)

My thinking is that 0launch could download the files and then start
the program using either pola-run or the Python Plash bindings.  It
would build an environment consisting of the files in the zero-install
package and its dependencies.  This way only the minimum required
installation files would be present in the program's namespace.

In the ideal case I am assuming that there would be no need for a
default environment, so it wouldn't grant access to /usr, /lib and so
on by default.  Are there any zero-install packages that provide all
their own environment, including libgtk, xlib, etc., through their
dependencies?

This assumes that 0launch is run from the user's namespace, not
sandboxed, and so is part of the user's Trusted Computing Base.


> The first command writes to the cache but doesn't run anything, while
> the second runs it but without write access to the cache.
> 
> My current thoughts are:
> 
> Provide a '0launch-restricted' command whose interface is the 'safe'
> subset of 0launch's (e.g., you MUST use '--download-only'). When
> 0launch is run, it checks whether it needs to download anything. If
> not, it runs the program. If it does, it runs 0launch-restricted (a
> plash executable object) to get it in the cache first.

I guess this works for a zero-install package that invokes another via
0launch (e.g. Gnumeric launching a Web browser to display help pages),
whereas my proposal above doesn't.  Are there zero-install packages
that invoke 0launch themselves?


> This is pretty easy to do, because it's the same check that we already
> do to decide whether to switch to GUI mode.
> 
> Some minor issues:
> 
> - When running without a GUI, it confirms that you trust new keys by
> reading from stdin, which I guess we wouldn't trust?
> 
> - The GUI will always label the button 'Download' rather than
> 'Execute'. Maybe it should just always say 'OK' to avoid confusion.
> 
> How to you plan to support configuration settings?

For configuration settings I think there needs to be an
installation/instantiation step, at which point several things get set
up:

1. The user gets to pick a "pet name" (and icon) for the application.
This is the name that will appear in the title bars of the
application's windows (although for the moment we can't enforce
that...).

2. The application is granted access to a freshly-created directory in
which it can store configuration settings.  Having an instantiation
step means you can create multiple instances of an app with different
settings (and pet names) if you so desire.

3. The application declares what file types it's prepared to handle,
and the user gets a choice of whether to associate those file types
with the application.

4. The user can install a launcher for the application instance
somewhere.  The location can be chosen via drag-and-drop or the
instance can just put in a default place like a "Start" menu.

5. The application can ask to be granted access to other things --
e.g. network access, configuration files such as ~/.gtk -- and the
user can grant or deny these requests.

I'm imagining something like AddApp, but with a few configuration
options.

Concretely, instantiating an app might work by creating a new file in
a directory in ~/.config which would list:
 - the zero-install URL of the application to launch
 - public keys to trust when fetching program code/data
 - pet name
 - files/directories to grant the app access to when running it

Then we could create .desktop files that refer to this config file.
These config files record what authority has been delegated by the
user, who can review what authority they have granted and revoke it by
changing or deleting the files.


> > I think the hard part is working out how to grant authority to the
> > zero-installed program.
> 
> > For a GUI editor we could generate a .desktop file (similar to how
> > 0alias creates scripts) and associate it with file extensions such
> > that when a file is double-clicked, the editor is launched with the
> > right to access the file.
> 
> I'd probably do that at the filer level (which is the graphical
> equivalent the interactive plash shell). Seems strange to be only
> sandboxing zero-install programs and not others.

Yes, ideally all programs would be sandboxed, but many programs won't
be able to work like that so we can't make that the default yet.

Also, I think this ought to work in other file/program browsers, such
as Nautilus, so that these can launch sandboxed zero-installed
programs.  I think the only way to do this is to generate a .desktop
file.  Or is there another level where we can hook in?


> If you want it to handle files:
> 
> - Open the menu over a file in ROX-Filer, and do 'Set Run Action...'.
> Drag the new launcher into the dialog box.
> 
> i.e., the user sets associations and chooses the launcher location,
> rather than the application doing it (as on Windows).

With Polaris you can set up file associations when you
install/instantiate the app, but this is under the control of the
user's agent (Polaris) rather than the app itself.  I believe it's
similar in CapDesk.

Cheers,
Mark