[packaging] Towards trusted third party repositories

Dan Kegel dank at kegel.com
Tue Oct 7 06:39:22 PDT 2008

I've been intrigued by http://en.opensuse.org/Standards/One_Click_Install
for some time now.  (That's a way to provide a one-click web
install experience for .deb/.rpm/.psi etc. packages, implemented
as a mime type handler that parses a simple .xml file pointing
to the package/repository appropriate for each distro.)
When this idea was brought up on the Packagekit mailing
list, it generated lots of negative feedback.  The summary at
gives a bunch of non-central objections, followed by
the central objection that one cannot trust third party repositories:
"Allowing to easily add third party repositories and install
third party software without a certification infrastructure is like
opening the gates to hell"

This is a real problem.   Here are a couple risks:
1) users might click on malware sites and add
completely malicious sites to their repository lists
2) a compromised third-party repository
might update system packages maliciously.
3) several genuinely well-intentioned
repositories might include conflicting versions of
a commonly needed package not provided by the
system repositories.

After mulling this problem over for a long time,
two ideas came to mind:

1) Since the distribution is trusted, it could decide
to trust some third-party repositories.  For instance,
it might decide to trust Adobe's hypothetical
repository so that people could get flash and air
updates straight from the source.
This idea of using the distribution as arbiter of
trust for third party repositories could be extended
to games publishers, etc.  This could provide a
partial solution to the first threat listed above;
if the "good" third-party repositories are already
known to the distribution, there's less need for users
to be doing something dangerous like deciding
on their own to trust a random third-party repo.
This addresses the first threat identified above.

2) A simple way to keep repositories from
updating packages they shouldn't is to
have package managers enforce some sort
of namespacing.  e.g. Adobe's repository
could be allowed to only update packages
whose names start with "adobe-".
(System repositories would continue to be
able to update any package at all.)
This addresses the second and third threats
identified above.

I think something like this is going to be needed
before we can have a thriving -- and safe --
ecosystem of ISVs providing
easily-downloaded-and-installed binary packages
for Linux.

What do people think about the package namespacing
- Dan

More information about the packaging mailing list