Re: [Plash] Packaging system

[Thomas Leonard]

On 3/10/07, Mark Seaborn <address@hidden> wrote:
> "Thomas Leonard" <address@hidden> wrote:
> > On 3/8/07, Mark Seaborn <address@hidden> wrote:

> > > I would rather just trust the key used to sign the debian Packages
> > > file.
> >
> > Doesn't that conflict with your next requirement:
> >
> > > > > "If sandboxing were added, the inability to distinguish kinds of trust
> > > > > would be a vulnerability."
> >
> > If all you can say is "trust the master Debian keyring", you can't
> > have different levels of trust anyway. If packages are individually
> > signed, you can apply whatever policy you please (including grouping
> > keys to get the Debian behaviour if you want).
>
> There's no conflict.  Each application instance can be installed from
> a different debian Packages file, and each application instance can be
> trusted with different authority.

So, if we have two programs that depend on GTK (Firefox and Pan, say)
then there will be two Packages files, each with their own maintainer,
each containing information about GTK?

You can do exactly the same thing in Zero Install (the Firefox and Pan
maintainers each also maintain a copy of the GTK.xml feed), but with
the added advantage that if both GTK binaries happen to be the same
then they get shared automatically.

But I don't like doing that, because you end up doing a lot more work
when a new version of GTK comes out (i.e. this also doesn't scale
well). So, the normal model is to have a single feed for GTK  shared
by both apps, with the app authors indicating the version(s) of GTK to
be used.

There are various ways of organising things, but I'm not sure what the
advantages are. All we really care about for the signatures is that
the identity is correct (i.e. that this really is GTK and not
something else). So, the only situation where your method would make
any difference is:

- I'm running two different programs (Firefox and Pan), both using GTK.
- Both download the feed http://gtk.org/gtk.xml at different times.
- Both versions of the feed are signed by different people, one
trusted by the Firefox devs and one trusted by the Pan devs.

Making that work doesn't make much sense to me. I'm *definitely*
running at least one malicious version of GTK - I want to be told
about that so I can investigate, not have them both run in parallel.

(the only case where you want to support this is when different users
are involved, since one user can't be allowed to prevent another from
upgrading, and we do this by storing the interface files per-user)

> It's a similar situation with version control systems.  When a piece
> of software is released, the developers are declaring that the code is
> of a certain quality, has been tested, etc.

Sure. I agree that being able to group things makes sense. The main
reason we don't do this automatically already is that it presents a
problem for the developer:

E.g. I'm prepared to sign ROX-Filer, since I wrote much of it and
built the binary. But how can I sign for GTK, which I didn't write?

We may want an 'insurance' model here. i.e. I haven't checked it but
I'll pay you if it's malicious. Obviously, as a hobbyist I can't do
that, although a commercial organisation could.

I could just be signing to say "this is the version I downloaded". If
the actual package download comes from the original source then this
can detect changes, which is quite useful. I probably need to codify
somewhere what the signature actually means.

[ recording the chosen versions ]

> > Yes. 0compile does it by running 0launch twice. Once in
> > '--download-only' mode so you can download with a nice GUI, and then
> > it uses the python API to write out the choices XML file, but the plan
> > is to have 0launch write the file directly.
>
> OK.  Presumably 0launch will be able to read the file to reproduce the
> environment as well?

Yes.

> > <feed-for interface='...'/>
> >
> > (we're often a bit loose with terminology though, because originally
> > we didn't have 'feeds' so I used the word 'interface' to mean both
> > interface and feed)
>
> OK, I didn't appreciate the difference.  But doesn't this have the
> problems I mentioned before?

Ideally, the 'interface' would be http://fsf.org/glibc.xml and Debian
and Fedora would each preconfigure their systems to use their own
feeds rather than the upstream one. Of course, you probably wouldn't
want to use Zero Install for something as basic as glibc anyway.

> "0launch --feed" is adding the feed to a global (well, per-user) list
> isn't it?  Does that mean that all applications that depend on the
> interface (assuming no versioned dependencies) will use the new feed?
> Is it possible to choose per-application?

Currently. no. None of the policy choices the user can make are
per-application. E.g., a user can't say that GTK 2.6.3 is 'preferred'
for ROX-Filer, while 2.8.1 is preferred for everything else. Only the
authors of the programs can say that (the reason is simply to stop the
user interface from getting too complicated).

[ As always, you could set up a second configuration directory and run
ROX-Filer with that. ]

> I noticed that where interface A depends on B, it is A that contains
> the <environment name="PYTHONPATH"...> setting and not B.  That seems
> a little counterintuitive.  It makes sense if this is seen as an
> argument to A, but then it contains a path into B.

It is an argument to A (although the process-wide scope of environment
variables makes this less obvious). The ability to specify a path
inside B is a convenience, since A (presumably) knows about the
structure of B and could append it itself.

> By the way, how about adding an apt sources.list line to the
> installation instructions for Debian etch on the Zero-Install web
> site?

Could do. I'm still trying to get it into unstable, but the mentors
mailing list is still ignoring me completely. If someone could post a
request (or sponsor it directly) that would be very useful.


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