Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local)

[Mike Hearn]

On Fri, 21 Oct 2005 16:59:38 +1000, Mike MacCana wrote:
> Why should Fedora and Red Hat encourage installing software in a
> non-standard method?

Because:

a) Fedora RPMs are not a standard method. They're proprietary to Fedora
   and a particular Fedora release at that

b) Non-technical end users like this particular non-standard method

c) It's more secure to use RPM for operating system level code and 
   something else for 3rd party application code.

I'll talk about the last one more in a moment, as I suspect you don't care
much for inter-distro compatibility or what non-technical end users want.
 
> How is it easier to have an application that installs in a totally
> different method from every other app on my system?

Have you ever tried it? I don't think ease of use is a real problem with
autopackage.

Anyway, this set of /usr/local bugs affects installing software from
source too, which is still VERY common amongst end users, mostly because
software people want is often not available in any repositories.
 
> This isn't a defence of RPM. It's a defence of good systems management.
> One way to install software is better than two.

You say this as if it's obvious. But to me it is not.

Let's talk about security. Hopefully it hasn't passed you by that despite
being basically miniature computers mobile phones have remained basically
impervious to viruses and spyware. Yeah yeah, I'm sure somebody can pull
up a scare story about a "virus" that requires you to manually confirm
reception and installation of the software, and which can then be
trivially deleted. But we've seen nothing like what we've seen in the
Windows world, where software gets in undetected and then makes itself
nearly impossible to remove.

One reason is that there is strict separation between 3rd party
application code and native OS code. Java MIDlets are an extreme example
of that, which can't access or control each other and run in an
interpreted sandbox. They also can't access operating system files
(although phones do have operating systems and they do store their code
and data in regular files).

By keeping application/game software totally sandboxed, the platform has
been (so far) kept secure. To upgrade the OS you need to reflash the
firmware, it's not like installing a regular application at all.

Right now we simply *cannot* do that on Linux because there is no
distinction between a kernel or libc upgrade and installing a new chat
client. When RPM is used for both, how can you possibly sandbox the
installation of this software? How can you say, well, THIS rpm can modify
the grub configuration but THIS rpm cannot?

You could try playing games with digital signatures - RPMs signed by this
authority can do anything, and RPMs that aren't signed cannot - but then
you did exactly what we did with autopackage and produce a new format. 
They might have the same file extension but they actually aren't the same
type of file at all. They have different capabilities and work in
different ways.

Anyway. One of the things we've been looking at lately is using the binary
policy modules in Fedora Core 5 to sandbox autopackages down so they can't
interfere with system configuration in unacceptable ways. We can do that
because we control the API and because the format was advertised since day
one as a way for developers to distribute their application-level software
to end users and not as a distro building tool. You'll never find a kernel
autopackage, so the format itself acts as the dividing line.

Through this technique and others (like whitelisting) we hope to improve
security far beyond what a "one size fits all" tool can offer.

> Don't try and encourage people to use two different packaging systems simultaneously.

Too late. The cat is already out of the bag, 250+ people install their
first autopackage every day and it's growing all the time. Why don't you
work with what end users want instead of what you believe to be
theoretically pure?

thanks -mike