Re: [Plash] Plash Wiki

[Thomas Leonard]

On 2/4/07, Mark Seaborn <address@hidden> wrote:
> The immediate reason for setting this up is to use it for planning new
> development.  In particular, right now I am working on a package
> system for installing Debian packages into Plash sandboxes.  There is
> more information on the wiki:
> http://plash.beasts.org/wiki/PackageSystem

Interesting. I hope you're aware of how much time making your own
package manager / distribution takes (speaking from experience here
;-) My ROX developement work really slowed down when I started working
on Zero Install. I hope the same thing doesn't happen to plash :-(

A few comments on the text:

> "Keys in Zero-Install are either "trusted" or not. They are not marked as
> trusted for a specific purpose. This can create a confused deputy
> situation. This is not a problem with Zero-Install as it stands, because
> Zero-Install packages all run with the user's full authority. If
> sandboxing were added, the inability to distinguish kinds of trust would
> be a vulnerability."

Just give each trust domain its own configuration directory. We already
allow different users to have their own sets of trusted keys, so that
extends easily to multiple sets per user. The software itself can be shared
in all cases (between users and between sandboxes).

However, I may change it so that the question becomes e.g. "Do you trust
this key to sign software from rox.sourceforge.net?". That will mean a
few extra confirmations in some cases, but it's not unreasonable.

Note that even if a user does trust your (malicious) key, you still
have to hack into some server they use, or be able to intercept and
change their network traffic.

> "You have to declare trust for authors/packagers of all dependencies.
> This does not scale."

We'll make it scale when we have enough packages ;-) "Trust all keys
on the Debian keyring" would be a possible policy, for example.

> "If sandboxing were added, the inability to distinguish kinds of trust
> would be a vulnerability."

One of the things I like about the plash model is that it doesn't have
these kinds of trust levels. I don't say "I trust gedit a lot"; I drag a
file to it to say "I trust gedit to read this file". Why is it necessary
to assign levels of trust to programs?

> "Zero-Install does not provide a way to refer to an immutable package.
> There is no way to reproduce a configuration."

This is not true. In fact, 0compile stores a complete record of the
configuration in a file called "build-environment.xml", so that you can
reproduce a build exactly using the digests of each dependency (header
files and build tools). It also stores the versions, in case you want to
use a different arch but still get it as close as possible. See the
Pager 1.1 binary for an example.

(there is currently a limitation that the versions must be cached,
otherwise it tells you to run '0compile setup', which has the side
effect of updating the selected versions, but I just haven't got around
to fixing that yet ;-)

> "Zero-Install does not make it easy for a third party to replace one
> package in a set of dependencies. To do this you would need to copy all
> the feed files and re-link them."

Also not true. For example, if someone provides an alternative to
ROX-Lib (used by many ROX applications), you can add it with:

$ 0launch --feed http://thirdparty.com/Alternative-ROX-Lib.xml

It gets the program to extend from the <feed-for> element. Again,
there's currently a minor limitation: you can't disable the default
feed, so when a new release of ROX-Lib comes out it may get selected before
Alternative-ROX-Lib is updated with an alternative for the new
version, which may or may not be what you want.

The current behaviour works well for CVS checkouts, where you want to
use whichever is more recent: your checkout or the latest release
(given that you may have forgotten about the checkout weeks ago).

> "Zero-Install doesn't have a tool to import a Debian repository's
> packages en-masse. You can convert an individual package but you'd have
> to follow the dependencies yourself and create a feed for each one."

This is an interesting one. I was recently challenged to produce a
version of svn 1.4 for Debian/stable. This involved creating Zero
Install feeds for 9 separate Debian packages! The whole process took
roughly an hour doing it manually, but it could certainly be automated.

> "Zero-Install packages typically have undeclared dependencies on
> libraries and tools that are assumed to already be installed on the host
> system."

On the TODO list ;-)


--
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1