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

Peter Dolding oiaohm at gmail.com
Fri Dec 5 21:43:36 PST 2008


On Fri, Dec 5, 2008 at 2:13 AM, Tortanick <tortanick at googlemail.com> wrote:
> On Thursday 04 December 2008 13:40:35 Dan Kegel wrote:
>> I've got a meeting wiki up at
>>   http://wiki.winehq.org/TrustingThirdPartyRepositories
>> It already lists the big issues that need discussing.
>> Please have a look at put your two cents in!
>> I will also put IRC information there when I have it.
>> - Dan
>
> Since you asked: my two cents:
>
> Suse's Proposal:
> Seems ok to me.
>
> Ubuntu/Canonical's Proposal:
> This works for trusted developers but I want a system that works with
> untrusted devs too, not blacklist material obviously but greylist stuff: good
> software that doesn't respect user sovrenty. For examlpe: a computer game
> with DRM or a media player that I want for one obsucre media format but tries
> to make itself default for everything.
> Finally there is always the risk of the whitelist maintainer becomeing a
> bottleneck.
>
>
> Upgrade Issues/Dependencies:
> I think the best solution is to have dependences on various parts of the LSB
> standard but prohibit dependencies on anything else, including other packages
> from the same ISV. So long as distros remain the primary choice for new
> software (and I can't see why they wouldn't) there probobly wont be enough
> ISV software on any one machine to justify the increased complexity of the
> package manager and risk of dependency hell.
>
> Package Name Clashes:
> seems good to me.

Part of the solution to this is in the LSB standard.  There was a
reason why LSB packages where meant to be relocatable.  If there was a
conflict user end could rename around it.  Also works around out of
disk space problem

Providing this solution up into the global space of package
installation is kinda required.   So yes the dependency location for
application may be changed.


> File overwrite issues:
> I'm a big fan of limiting ISVs to /opt/vendor/program with xdg-utils allowing
> a few special cases out into the wider filesystem. I'd go for package manager
> enforcement rather than distro enforcement, distro enforcement is a whitelist
> system and as I said above I want the LSB's package manager to be designed
> for safely installing greylist software.

File overwriting for most of the FHS world has become not required.
Even outside the applications install path.  Please beware
/opt/vendor/program is just a LSB recommend default location.
Always by LSB end user has had the right to relocate that.  All binary
should be restricted to the install path and applications always be
relocatable.  With the option of adding the applications /bin
directory to the global paths at user option.

Same with providing virtual links.  Remember any other package manager
conflict equals package not installing.

The .d directories have been mostly created so installing applications
never ever should need to overwrite another applications configuration
alterations.

Nothing in the operation of xdg-utils should require a overwrite
approval unless something has not been uninstall correct or user is
installing duplicates.

Now case of duplicate throw up the option to rename is a really good
thing.  Bit like installing a LSB gcc and it wants to replace
/usr/bin/gcc of course user may wish to rename that to lsb-gcc.

Good design really required package to provide secondary names for any
file that could be duplicate and even itself.  One part of optional
secondary names is of course the repository it comes from.  Like gcc
since its a lsb vendor lsb-gcc now conflict again lsb-gcc-version  Now
hopefully not conflict.  Yep longer and longer names until no conflit.
 Of course user will want to type the shortest name for the one they
use all the time.  So most important is that in the case of conflict
that the user has the right to have the other package that is in
conflict with the current package being installed to be renamed.

Rare tools that like system wide configuration tools that need to
truly overwrite files should be going threw policykit or something
like it not package installation.     Package installation at most
should be alter name of something.

xdg for menu entries also need the power to do renaming as per package
instructions.   A web developer may want many versions of Firefox
installed and different entries for them all.

Worst area for conflict that is hard to solved is in the users own
home directly.

Problem is simply solved by giving users powers.  Yes this is
different to the distribution model.

Bigger problem not on list is how will conflicting dependencies be-handled.

Userid is a crappy solution.  We have xattr that can connect a package
id to a file and package databases that keep a complete list of what
files a package installed.

Now better way is simple.   A Null user runs the installer.   Exactly
that a User with no right to do anything.  Only way it can do
something is call a service like policy kit.   So installer want to
put a file system it asks the service to do it.  No fancy suid
wrapping.   All operations can be logged by the service.  Service can
ask user for input in case of conflict.  This way the installing
package a no final say on anything.

The most evil thing currently to deal with is Linux Security Modules.
How is the package going to install the right security around it self.
 Selinux smack apparmor....    We really don't want programs like ping
being given the means to write to every users directory when they
don't need it.  Yet it still need to be able to access the network to
operate.

Peter Dolding


More information about the packaging mailing list