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

[Mark Seaborn]

Subject: Re: Zero-install and Plash
From: Mark Seaborn <address@hidden>
To: address@hidden
Date: Tue, 18 Jul 2006 21:57:06 +0100 (BST)


"Thomas Leonard" <address@hidden> wrote:

> On 7/17/06, Mark Seaborn <address@hidden> wrote:
> > "Thomas Leonard" <address@hidden> wrote:

> > 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.
> 
> It's a bit tricky. For example, ROX-Session depends on ROX-Defaults,
> causing XDG_CONFIG_DIRS to include a directory in the cache with
> sensible defaults. Other applications inherit this environment.

I guess the default file associations would need to be set up a
different way?  e.g. Have a way of instantiating a bunch of
applications at once.  This would only be an issue when installing ROX
on an existing desktop; a newly-installed desktop could instantiate
the defaults when you create a user account.

> Also, the cache is read-only, public (and probably shared over p2p at
> some point), and contains impossible-to-guess directory names
> (preventing accidents), so there's very little to gain by restricting
> access to it.

By public, do you mean you can set file permissions so other users on
the same machine can use your cache with zero-install?

I think the main practical reason for creating a minimal environment
(besides the general principle of least authority) is to be certain
that the behaviour of the programs you run is reproducible, so that
they are not accidentally depending on other files.  That's why people
use tools like pbuilder to set up chroot environments.

Is there any reason not to create a minimal environment?


> > 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?
> 
> No, but we may start listing them at some point. That would allow the
> injector to select an older version of a program if a required native
> library was missing, and to choose between a native library and a zero
> install one (people keep complaining about having to download
> libraries they already have).

Would you have to introduce another kind of declaration into the
zero-install feeds to specify that, say, the file "/usr/lib/libX11.so.6"
is good enough to satisfy the dependency, or the Debian package
"libx11-6" is good enough?

Another technique would be to require a specific version of a file (by
hash), and look in /usr to see if it is already available.

> > Are there zero-install packages
> > that invoke 0launch themselves?
> 
> Some of them. Build scripts (e.g. rox-release) are normally sandboxed,
> and tend to run 0publish and gtk-2.4, for example. At some point, all
> the build tools are likely to be run this way (gcc, scons, ...).

How are the build scripts sandboxed?


> > 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.
> 
> OK, here's an idea. AddApp already creates a ROX application directory
> for the launcher - how about storing the configuration settings in
> there?
>
> - Multiple configurations happen naturally.
> 
> - Deleting a 'launcher' deletes the configuration settings (no pile-up
> of forgotten config files in hidden directories). Would require a bit
> of user re-education.

You could put the config settings directory there, but I think the
file that specifies the instantiation should go in a central location,
for two reasons.

Firstly, it can be quite sensitive, in the sense that it would list
files to grant to the instantiated application.  So if we accidentally
granted it the right to modify that file, it could grant itself access
to anything by adding filenames to the list.

Secondly, if the user is to be offered the facility to review what
authority they have granted to instantiated applications and maybe
revoke it, there needs to be a searchable list of what they have
granted.

The full answer to these problems is to have a persistent
object/capability store.  In such a scheme, an application instance
would be an object with references to objects it has been granted
(such as its configuration directory).  The application would be able
to store futher capabilities that it has been granted (e.g. via a
powerbox or drag-and-drop) and retrieve them later, including after a
reboot.  Similarly the user's Start menu (or similar) would contain
references to applications' executable objects.

I'm proposing flat files initially for simplicity, but planning to
evolve it into an object store in the long term.


> > 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
> 
> Per-program keys is an interesting one. So far I've resisted, because
> the extra confirmation dialogs might be counter-productive.

Is it necessary to ask the user to confirm the public key associated
with each zero-install feed?

Suppose feed A depends on feed B.  Couldn't feed A list the public key
used to sign feed B, so that the system can check that B's interface
comes from the source that A expected?

Then we would be left with just one public key for the user to check
per application started with 0launch.  We could eliminate that too by
including the public key in the feed's URL -- although that assumes
that feed URLs are always received via a secure channel.

Cheers,
Mark