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

[Richard Hughes]

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.

> * 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?

> * User finds a tutorial explaining how to accomplish a goal, which
> requires some software to be installed.

I think that's a little of a different use case - i.e. install more than
one thing at once using an external file.

> If we look at some examples of you get from a project/product web page
> to install some software right now, such as pidgin[2], amarok[3],
> amazon mp3 downloader[4]... They usually involve first the user to
> drill down selecting their distribution and version, and then the user
> either gets an individual rpm/deb package or complex instructions
> regarding adding a package repository and installing the software.

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.

> It is quite possible to implement a OCI handler for every
> distribution, which does the right thing with each distribution's
> package management. If OCI could be built on top of packagekit then a
> single handler could work on every distribution with a packagekit
> backend implemented. Indeed, it would seem foolish to implement a
> distribution specific packagekit implementation, and then have to do
> the same again for an OCI handler. As far as I am aware it is not
> currently possible to implement using the packagekit API, as there
> appears to be no way to add or remove repositories[12].

Agreed. I'm not sure adding and removing repos is something we want to
make easy for the user. Adding a repo is quite an implicit trust. But
I've spouted stuff about that in the past.

> Installing packages built for an entirely different distribution is
> clearly a bad idea, although many people do it with random packages
> they find online.

Sure, it's an amazingly bad thing to do. It's like windows users running
game.exe from some random site. Security = *puff* :-)

> This is indeed a problem, and has often caused upgrade issues for suse
> users. The upgrade can usually be performed without problems by
> disabling all old repositories, adding the new repositories, and
> upgrading. Unfortunately this method often means that removal of old
> third party software that is not available in the distribution is be
> required, as its dependencies will not be satisfied on the new system.
> Although this can be suggested and performed automatically the user
> does not really want to lose all his/her third party software.

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.

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

> Zypp on suse solves both of these problems by using "vendor-sticky"
> updates will only be chosen from the vendor that the user chose to
> install the package from in the first place. The user must make a
> specific choice to change the vendor of an installed package. This
> seems to quite effectively solve the problem, a similar but less
> effective result can be achieved by adding third party repositories
> with a sufficiently low priority. Of course these strategies only help
> under normal circumstances, they do not defend against malicious
> content in a third party repository, which comes back to trust again.

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.

> This often means that a project cannot distribute software that
> infringes software patents in the united states, whereas a separate
> entity with no ties to the united states could happily distribute that
> software for other users of the distribution. There is also the
> problem of incompatible licences, or licences that prohibit
> redistribution. Like it or not there are ISVs shipping non-free
> software to linux users. From games such as ut2004, to software like
> skype. Neither is redistributable, is it better that these companies
> all NIH[16] their own installers, and make it difficult for users to
> remove the software afterwards, and the system's package management is
> unaware of the presence of such software?

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

> Telling vendors they have publish their software under a specific
> licence, or that they must work under the distributor's own policies,
> procedures, and timescales to reach users seems like a good way of
> discouraging vendors from targeting your distribution.

The closed source vendor will have to work with the distro in a timely
way for things like releasing security errata - as the closed blob
surely will be static linked with broken versions of the new libraries.
I don't think that you can argue OCI as a way to make Linux more
enticing to existing ISV's.

> Many distributions operate on a stable release every $TIMEPERIOD
> system, that involves freezing the versions of applications bundled
> with each version of the distribution for the lifetime of that
> distribution. While this is great for ensuring that that software all
> works well together, where does it leave the person who needs to
> follow the latest version of $APPLICATION for his/her work? e.g. A
> java developer might require the latest version of eclipse/netbeans
> and other java productivity software. Should he/she follow the
> unstable branch of the distribution just so that he can have the
> latest software? Or should he install the software manually on the
> stable version and lose all the benefit of the package management
> system? In openSUSE it is common to use third party repositories to
> allow special interest groups to follow current versions of specific
> software on the stable version of the distribution. There are
> repositories for latest java tools, latest KDE, etc. The users can
> keep their stable supported system and install the newer versions of
> the software that they require.

Right, there's no way to do this in PackageKit right now. From a distro
point of view I would think the dependancies and soname versions would
cause major headaches with some of the system unstable and some stable,
but I've not looked into how the SIGs work in openSUSE.

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

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

> In some ways I think that the argument that making things easier makes
> it easier for users to do the wrong thing is a bit like the security
> by obscurity argument. Sure, if the user can't work out how to do
> something then he/she will not do it wrongly. However, if the is able
> to do something and does it wrong it is not really the fault of the
> software for being too easy to use, but rather that it was poorly
> designed and did not give the user the correct information and
> guidance.

No, if we say to people "use the one click link to install the latest
version of unstable gimp" they will. And when it crashes, they'll send
angry bugzillas to the distro bugtracker. Which will be ignored by the
developers as it's some old (2 weeks old) svn snapshot that replaced
their system copy. Real developers will checkout the code from svn, and
run it in /var/local or a home prefix and then just blow away the
changes when done. Their system "distro-supported" copy is not changed.

> Apologies for such a long message, but there were quite a number of
> points to respond to. It would be good to get other people's opinions
> on these matters. If OCI is a good idea then it would be much better
> if it would work on any distribution, and we can enhance the format if
> necessary to accommodate others. If it is a fundamentally flawed
> concept then we should probably not even be using it in openSUSE.

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

Richard.