[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Plash] Packaging system
Re: [Plash] Packaging system
Sat, 17 Mar 2007 18:04:58 +0000
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
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?
> <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
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