[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Facilitating external repositories

Hi Chris,

On Sat, Jun 06, 2015 at 11:49:21PM -0400, Chris Knadle wrote:
> Hey, Wouter.
> On 06/04/2015 12:18 PM, Wouter Verhelst wrote:
> > Hi,
> > 
> > At $DAYJOB, I'm maintaining a few repositories with ready-to-install
> > packages for a number of distributions[1]
> > 
> > Currently, the instructions[2] say to do the following:
> > - Download and install an "eid-archive" package, which contains the GPG
> >   keys and generates a sources.list.d file for the repository;
> > - Run "apt-get update";
> > - Install the "eid-mw" and/or "eid-viewer" packages.
> > 
> > This works, but it has a number of downsides:
> > - The second step, "run apt-get update", is often overlooked; this seems
> >   to be the case especially for users of Ubuntu, where the default
> >   handler for installing packages is the "Software Center", a GUI
> >   software management tool that doesn't have any UI element for doing
> >   (the equivalent of) apt-get update
> Huh... this is unfortunate.  I can imagine a package that installs some
> kind of one-time cronjob that will execute 'apt-get update' a minute
> later, but I don't like the idea... I hope there's something better
> available.

I could use an "at" job, but that isn't part of the essential set or
installed by default (nor is cron) on some derivatives, so that doesn't

> > - There is no trust path from your already-installed distribution to the
> >   "archive" package (yes, I did sign the gpg keys; no, I don't consider
> >   that enough).
> Yeah unfortunately this is sort of a catch-22 problem... IMHO we want an
> external archive key to be easily replaceable in case it's ever
> compromised, yet we also want that same key to be "easily trust-able",
> which takes time and several signatures of known keys to do... i.e. an
> investment.
> I recall the prior DPL wanting to support PPAs in Debian, and I would
> imagine that this issue is one of the "sticking points" to that idea.
> BTW does the 'debian-keyring' package exist on Ubuntu and Mint?


> If so I could imagine that your eid-archive package could have a
> pre-depends on debian-keyring and check that GPG keys installed by
> eid-archive are signed by a DD or DM.

That doesn't fix the trust issue.

Any trust checks need to be done by something which has first been
verified to be trusted code. If you have a package test its own
trustworthiness, then that code is running before its trust has been
checked, and therefore the trust check is worthless.

Think about it. A malicious package could just claim to be

So, for there to be a valid trust path, the trust needs to be verified
by something inside the Debian archive.

I had indeed been thinking about a tool which would verify that a GPG
key is signed by at least one person inside the debian keyring, and if
so, enable the archive and possibly do an apt-get update and maybe
install a default set of software provided in the configuration file
(which would need to be signed too, for this to be safe). Such a tool
could register a mime type for a particular format of configuration file
that it understands, which would allow a repository maintainer to add
something to a website which a user can download and automatically open
inside this tool.

That would solve the usability issue ("click on a link, tell browser
to open with default program, everything else is automatic"), and would
sign the trust issue (since it is code inside the Debian archive which
does all the verification). However, I wanted to check first whether
something along those lines already existed.

It now appears that it does not, so I'll have to start hacking.

It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Attachment: signature.asc
Description: Digital signature

Reply to: