[packagekit] 1-click; Third party vendors; etc.

[Benji Weber]

2008/6/2 Richard Hughes <hughsient at gmail.com>:
> On Mon, 2008-06-02 at 13:12 +0100, Benji Weber wrote:
>> I have been watching with interest the discussion of one-click and
>> third party repositories resulting from fosscamp on this list. I have
>> been too busy with exams
>
> Sure, exams first, then hacking. I had to keep telling that to myself in
> my final exams last year. OSS will always be here - exams do not
> move! :-)
>
>> b) Software is only locatable based on metadata supplied by the
>> packagers - name, summary, provides...
>
> Sure, but then these are localised by the packager or distribution - I
> couldn't find one example of a OCI being localised into different
> languages - which is a big issue for me. The onus is on the packager to
> arrange this - and most don't.

Correct. The format does support localisation (here is an example
http://download.opensuse.org/YaST/Repos/_openSUSE_103_Default.xml) but
it is infrequently used. The lack of processes for having arbitrary
things translated has caused difficulty for infrastructure that is not
in the wiki, such as help.opensuse.org and software.opensuse.org as
well.

>> * User finds a product's webpage, thinks this looks good, wants to install it.
>
> Users want stuff to work. Security comes later. If I posted a message on
> nvnews telling people they can get compiz working using the nv driver as
> long as they login as root, I suspect a good majority of people would do
> so - even though there are several high profile warnings about running
> applications and a desktop sessions as the root user.
>
>> * User purchases or is given a DVD containing some software, wants to
>> install it.
>
> Do I trust the CDROM? Can you use a signing infrastructure with OCI
> files?

Of course, the OCI file simply contains instructions for the normal
package management system. The user will be shown the key and will
choose whether to trust it or not (Unless he/she has already trusted
it). Something like http://files.benjiweber.co.uk/b/gpg2.png will be
shown. I believe this dialogue has changed a bit, that was the newest
screenshot I could find.

> Sure, but in the case of amarok or pidgin it's nicely packaged up by the
> distro. I'm not sure what you aim to fix by providing a OCI for pidgin.

Installation from context. These things are packaged in the
distribution, which means that the site could include instructions
something like:

1: Open package manager
2: Search for package pidgin
3: Mark for installation and click install

* You have to hope that the user knows what a package manager is,
though you could explain it.
* You are asking the user to perform a sequence of steps to install
the software.
* The user already located the software on the web page, why should
he/she have to locate it again in the package manager?

It is like documents without hypertext - "to find more information
search for the following keywords"

> So the user looses. I would love to explain that to my dad. "Hey dad,
> the soduku game you downloaded as a OCI from freegames.ru has to be
> removed because it links against an old version of openraw that the new
> distro update doesn't provide - can I still update your computer?" --
> the answer will be no. Soduku vs. security, the former wins for him.

Well the system does suggest the best course of action. If the user
makes an active decision not to upgrade that is his/her decision. I'm
not sure what you are suggesting here - that it is better to deprive
the user of suduko in the first place than having the choice?

>> There are other ways to solve this problem though. Such as having the
>> upgrade process check each of the repositories enabled on the system
>> for some metadata indicating an update path, and/or asking a central
>> service for suggested replacements for the repositories in the new
>> version.
>
> Fail.

Care to elaborate? Offering third party vendors an upgrade path seems only fair.

> If I have problems understanding repo priority, how are we going to
> explain that to the end user. "You can't install that new version of
> VMWare as it is already provided as an older version in a repository
> that has higher priority" - what will the user do? They'll change the
> priority of the repo.

Vendor-Sticky removes the need for an understanding of repository
priority. The user is free to choose to change the vendor of some
software, but must explicitly choose to do so. The vendor will never
be changed automatically during an update, packages will get updates
from their original vendors. Different vendor packages will not be
automatically pulled in as dependencies without the user accepting. As
I said, some of this behaviour can be created with repository
priorities, but it does not work as well.

> Right, and the NIH problem isn't going to go away. tbh, I'm not that
> interested in the non-free software stuff.

But vendors might be more willing to work with the system rather than
against it if it was less hard for them to do so.

>> a) You control the process.
>
> Users are stupid. They don't care about the process, they just want to
> get stuff done. Explaining the finest nuances of soname versioning on my
> dad is just an exercise of patience, and a complete waste of time.

That was not my point. My point was that if users are using the
package management system to install software rather than using random
installers then there is at least some opportunity for the system to
protect the user from accidental system breakage and installation of
malicious software. When users are just executing an unknown binary as
root there's nothing that can be done.

>> If you wanted to do something malicious to a users' machine, why would
>> you utilise a process that requires the user to trust your identity
>> and be presented with warnings telling them that it is potentially a
>> bad idea? It is considerably easier to get users to execute arbitrary
>> binaries.
>
> Sure, but with a repo that's been added, it's not a one-shot window in
> executing code (like running a file) but it happens every time the user
> updates. Having a repo is a permanent trust relationship. With Livna I
> trust that it won't:
> * Introduce trojans in post-inst scripts
> * Leave me with security vulnerabilities
> * Replace any of my core files
> * Read or modify any of my documents
>
> I just can't do that with some unknown repository from a random developer.

I agree completely. The user must choose whether to trust the identity
of the repository publisher.

> Well, honestly, I think that OpenSUSE is the only distro promoting it to
> users. Tell me if I'm wrong. Cheers for your mail.

You are not wrong, although as I mentioned other distributions have
projects such as Third-Party-Apt. I think that openSUSE's use of it is
a consequence of the history of the distribution, which has only
recently been opened up to community contribution.

* Before the openSUSE project there was already a large community
contributing things the users required. As contribution to the
distribution itself was not possible, they made software available in
additional repositories.

* There were always (as long as I remember) new packages of major
software such as KDE released for all supported versions of the
distribution. This was one of the reasons people would choose SUSE.

* Now that contribution to the distribution itself is possible there
is still a motivation to keep the core somewhat clean, as there is a
common codebase with SLE.

These reasons and more may explain why the openSUSE community accepts
third party vendors and wanted a way to make it easier to use software
from them. The culture is quite different to the debian culture of
getting everything "into debian". It did somewhat surprise me how many
people believe the distribution should ship /all/ software rather than
providing a base upon which others can build.


--
Benjamin Weber