[packaging] Meeting next week to discuss trusted third-party repositories

[James Antill]

 As a developer for a used package manager, I've tried to stay out of
the "discussion" that is autopackage/0install/relocatable-packages
etc. ... if people think that those things can be usefully solved even
with all the historical evidence to the contrary then please just go do
it, you don't need my opinion that it'll fail and why, and we'll
presumably all be using it in 5 years instead of dpkg/rpm¹ (if you
succeed). At which point it'll be trivial for the LSB to adopt the std.
of what everyone is doing.

 But I'm sending this due to the respect I have for Dan and to try to
clear some things up from the non-ISV side ... as should be obvious,
this is all personal opinion blah blah. Anyway...

On Thu, 2008-12-18 at 10:15 -0800, Dan Kegel wrote:
> On Thu, Dec 18, 2008 at 10:05 AM, Thomas Leonard <talex5 at gmail.com> wrote:
> > 2008/12/18 Dan Kegel <dank at kegel.com>:
> >> The energy that goes into the posts on this thread is impressive.
> >>
> >> Can some of that energy be redirected to implementing?
> >
> > What do you want implemented that isn't already? What problems have you had?
> 
> Personally, I would like to see some of the ideas in
> http://wiki.winehq.org/TrustingThirdPartyRepositories
> put into action to lessen the pain of ISVs who want to
> provide commercial (including free-to-use) linux apps.

 The fundamental problem with that idea is that you are starting out
with "untrusted data from XYZ" and trying to find a technological
solution to make that "trusted data from XYZ".
 I don't think you can do that (or at least do so for usable
applications). Flash games/video-players are about the only thing that
comes to mind where this has been even remotely successful.

 Even at it's simplest form, where you have basically a
tar/cpio/whatever container for a number of streams of data that go
directly onto the disk, you still _have to trust_ those bits of data.

> Looking at Ubuntu, for example: I think Ubuntu 9.04 is going to whitelist
> a few third party repositories, that's kind of a given now.

 My only real wonder here is on how fast/far this will blow up in their
face, assuming they do this.

 You might think that's harsh/unfair but look at the history: remember
when GNOME did a "new desktop" spin on top of stable Debian; remember
when Fedora had Core vs. Extras; 100% of the time when random /. posters
talk about "rpm hell" when they mean is "I installed external rpms (read
had more than one "repo"), and then everything failed horribly at some
later point".
 In none (or very close to it) of those cases did someone do something
that intentionally would "break", indeed they were often trying hard to
integrate. But it didn't matter.

> It would be nice if they also supported some subset of Suse's
> OneClickInstall .ymp metapackage idea.

 You can do this now, in most package managers, by just turning all the
security off. That doesn't mean it's a _good_ idea though.

> Further down the road, I'd like to see dpkg
> provide better support for packages without control scripts.
> I'd also like to see better support for safely using not-yet-completely-trusted
> third-party repositories (including install-time measures such as
> 'can only install files into /opt/$vendor', and perhaps run-time measures
> such as 'apps from this repository are run in a sandbox').

 So even ignoring that some user is going to be using those installed
files, and thus. they need to be trusted (or so locked down as to be on
the level of flash games) ... what about the "Require:" stanza? Surely
that's useful, yes? ... but it's also _trusted data_, if you misuse it
you can force users to install other software with security errata, etc.
etc.
 Then, as an example of the next layer of trust pain, you have the
machine resources like disk or network bandwidth ... these are trusted
resources, which AFAIK all useful package managers will use depending on
the data they have access to (for updates etc.)


 So if/when you concede that you need to trust the package data, the
problem reveals itself to be much simpler:

1. You have legal problems with grouping certain things in a single
repo. (so Oracle/picaso isn't going to be shipped in Fedora/Debian).

2. You have technological problems with grouping certain things in a
single repo. (basically FOOXYZ is a junk package, so isn't going into
the repo).

...#2 is solved by fixing the problems and not at all by making it
easier for the ISV to ignore them. #1 is solved by the ISV fixing the
problems, or at worst to have specific "this repo. violates these legal
statutes/rules" al. la. rpmfusion-nonfree, and again is not at all
helped (for the user) by making it easier for the ISV to ignore the
problems.

 Again, all my personal opinion, I do not speak for anyone else.


¹ But that time would be _much_ better spent improving either one, as
given the problem "we have 2 major packaging formats, which also don't
do XYZ" I would not assume a solution of "we'll create a 3rd format"
being the correct answer.

-- 
James Antill <james at and.org>