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

[Tortanick]

On Thursday 18 December 2008 23:12:45 James Antill wrote:
>  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.

Welcome to the list, I was hopeing I'd get to see the viewpoints from 
developers of the current major package managers. 

>  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.

Its true, however the fact remains that either you use the untruseted software 
or you find an alternative. My useual response is find the alternative, 
that's why I left Windows for Linux and happily frolock through Debian's 
repoistory of trusted software. However the fact remains that for a certain 
class of software: games (full apps, not just flash), I can't replace 
untrusted software with trusted because every game is unique. Since I want to 
play the games I'm pretty much stuck trying to find a solution to an 
unsolvible problem.

When I suggest technological safeguards its not because I believe they will 
stop a ISV determined to ignore good practice but because firstly it will 
prevent honest mistakes from those that actually want to do things properly 
and because even if its mostly ineffective its still better than nothing and 
certianly better than installing a DRM infected game as root. 

The other thing I would like to do is have a distributed trust network where 
anyone can run a trust server and review packages for good behaviour, both 
pre and post install. Users would configure their installer with a list of 
trust servers they like and before installing new packages the LSB package 
manager would collect all comments about that package. At worst its would be 
an effective early warning system, at best a large incentive to behave. 

> > 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.

That's why I don't think third party packages should be aloud to require 
anything that isn't spesified by the LSB, you can't create dependency hell 
without dependencies. 

> ¹ 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.

To me it was never that the current systems are missing features but that they 
were designed for a compleatly diffrent use-case: Fully trusted software with 
lots of dependencies, as opposed to untrusted software with few depenencies 
and trying to combine two diffrent, conflicting (e.g. current pacakge 
managers must be root, for unstrusted software you want to avoid root) sets 
of requirements in one program was a bad idea. Is that wrong?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.linux-foundation.org/pipermail/packaging/attachments/20081219/308cc54c/attachment.pgp