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

Peter Dolding oiaohm at gmail.com
Sun Dec 14 18:44:19 PST 2008


On Mon, Dec 15, 2008 at 6:48 AM, Thomas Leonard <talex5 at gmail.com> wrote:
> 2008/12/10 Peter Dolding <oiaohm at gmail.com>:
>> On Wed, Dec 10, 2008 at 11:58 PM, Thomas Leonard <talex5 at gmail.com> wrote:
>>> 2008/12/10 Peter Dolding <oiaohm at gmail.com>:
>>> [...]
>>>> One thing Yfrwlf did not say is that Zero install and Klik were put
>>>> forward as possible packaging models for the LSB.   Major reason why
>>>> they are not yet is lack of formal way to register there files in the
>>>> packaging system.  Yes either one could be the formal package format
>>>> of LSB in time.
>>>
>>> Distributions can register their packages as dependencies for Zero
>>> Install packages:
>>>
>>> http://0install.net/distribution-integration.html
>>
>> That integration is part a joint project between LSB people behind
>> ISV's and Zero install.
>>
>> http://www.linuxfoundation.org/en/Berlin_Packaging_API is what has
>> been put forward to make it simpler on Zero install and other systems
>> like it.
>
> Is it for Zero Install? I can't see how we'd use it. As far as I can
> see, the only effect of registering anything with the native package
> manager would be the possibility of changing the behaviour of
> distribution packages (e.g. registering a newer version of GTK might
> change the behaviour of Gimp). Why would you want to do that? I'm sure
> the distributions wouldn't approve. Who would have permission to call
> these functions?
>
> I much prefer the current system, where I know that adding a new
> program isn't going to affect any existing programs.

That comes down to how its registered.   If vendor-gtk was the tag
thrown into the native package manager applications making up the
native distribution would not even see it.    Since they are looking
for the tag gtk.  Yes having a formal standard on naming is kinda
required to avoid distribution third party conflicts in the package
manager.    Advantage of the Berlin packaging api is that even if
applications throws up like name gtk that could conflict with
something in the distribution since installer has to pass all its
operations over to Berlin it can be appending a separation tag.
external-vendor-gtk could end up in the package manager when installer
requested to install vendor-gtk.   So conflict there is really simple
to fix.

Handling the package manager is simple.   Handling the dynamic loader
system correctly is more complex.   http://openlina.org/ handles that
issue by placing all its applications in a chroot.   So yes openlina
applications are another one that could be registering its
applications in the main package manager database.  0install handles
same issue another way.

Since openlina dependencies  are all inside chroot applications
outside are not effected.   Major reason for them wanting to register
in the main Distribution is for end user so they only have to go to
one place to remove applications.

The real nasty one is not the package manager or the .so files.  Its
making sure configuration files don't ever conflict and if it ever
happens there is a way out.  A user friendly way out.   System wide
chroot fixes.  Home directory is worse.

>
> [...]
>> 0install does have its flaws as
>> well.
>
> Quite possibly ;-) But what would be really useful would be specific
> reports from software authors, e.g.
>
>  "We want to distribute our web browser / game / whatever. We read
> the Zero Install packaging tutorial[*], and 15 minutes later we still
> hadn't managed to publish our program. The reason was ..."
>
> [*] http://0install.net/injector-packagers.html
>
> Likewise for the other options. Otherwise we're just guessing about
> problems that people might have, rather than trying to solve the real
> issues.

I am not guessing.  Most common flaw with 0install is fine grained
security not being used when its on offer.  Selinux Smack and so on.
Not used to reduce the damage a 0install application could do to the
user account.  Not all applications need to write files everywhere in
the user account.

Also as a system admin I personally don't like users installing files
in there own accounts.  In fact I go as far as having a filter on
there accounts so they cannot.  It selinux based and it does kill zero
install out right.  Yes symbolic linking from the home directory still
end up on the wrong side of it  had to block that after some
pranksters started tricking dumb users into ln -s /bin/rm ls and the
like .   Yet I still would love to have something like zero install in
my tool set for applications distributions don't ship.

Not registering in package database makes 0install harder to track for
system admins.   Lot of tools out there will pull the main package
manager database to a central location for monitoring.  Central
monitoring and Central deployment are things system admins want.
Basically any system like 0install openlina... that wants to exist to
make system admins happier Berlin design exists.

0install is not space effective system admins don't want symbolic
links for no good reasons.  Yes there needs to be a true global
install option.   System admin wants says users get X applications
done once no crud in there user accounts to back up.  Yes you can keep
user groups working with each other option.   Just please add the
option for system admin who are controlling exactly what there users
are using.

Apparmor is on the never to be used list for secure systems.   Due to
the fact of a enforcement error in its path based system making it
escapable.   So yes there should be either a smack or selinux profile.

Hopefully at some point 0install moves from sudo to policykit where
user can set the applications that can attempt to interface with the
cache directly.  It blocks malicious applications from trying to
interface with stuff like zero install.

That is not a software authors problem.  That is a person like me
problem.   I try to run highly secure systems 0install is kinda
lacking in my needs.   Auditing and securing is major parts of a
system admins job and 0install is making it harder.

By the way dep and rpm integration 0install currently got could be
expanded a lot by integrating with http://packagekit.org/

\packagekit can be used to create base frameworks to install into lots
of distributions out there.

Same issues hits packagekit how to avoid conflicts and how to be
secure.  It is the issue we have to solve.

0install is doing a really good job of remembering the developers and
the users.   Its forgetting the admin's who have a different set of
preferences and some of the things it doing its becoming hated by us
admins.   Admins not the people you really want to be annoying we do
have selinux and smack in our toolkits to make stuff we don't like not
functional.

Peter Dolding


More information about the packaging mailing list