← Back to team overview

ubuntu-appstore-developers team mailing list archive

Embedded package signatures vs. transport level security


        Hi all!

as a followup to a chat with Stuart, Colin, Martin and others it
appeared that we need to agree on package signatures and I wanted to get
input from this list.
  This topic is mostly about guaranteeing authenticity of the package,
to deliver it securely so that it can be trusted by the client.

There are generally two ways to approach this:
1. package is always transported securely: developer uploads package
   to appstore over https, appstore serves it over some secure channel
   (could be https too) to clients


2. signature is embedded in the package at build time (developer
   workstation) and verified on the client[1]

The current approach with .deb packages served by APT is of the first
type; approaches on other mobile OSes are more commonly of the second
type where you can host e.g. an .apk on your personal website.

Concerning the secure transport option, https or generally SSL are a bit
of a concern due to various attacks and problems with root certification
authorities.  This might be mitigated by DNSSEC and/or independent
generation/management of certificates.

Concerning the signed package approach, here are a couple of
implementations that would make it possible to sign the manifest and all
the package contents:
a. dpkg-sig[2]; I believe this generates an index called "digests" of the
   components of the ar file with corresponding SHA1 and MD5 hashes,
   then adds a GPG signature of that file as digests.asc to the

b. GPG signing the .deb directly

One thing which the signed packages approach make harder is to build
packages in a PPA; you'd have to build native packages locally and sign
them, or fetch them securely from your PPA then sign them.  But
supporting multiple architectures is probably a larger discussion that
we want to have separately, e.g. we don't have direct support for Click
packages coming out of PPAs.

I'm personally in favor of generating packages with embedded signatures
which you can then share on the web, send directly to your device etc.,
and an approach similar to dpkg-sig would seem fine to me, but I'm
curious to read what others think of the pros and cons of each approach.


[1] /usr/share/keyrings/debian-keyring.gpg is 44M for ~1000 signatures,
    so non-trivial size but probably due to signatures; if it's a
    problem we could either just ship fingerprints of truster developers
    and fetch keys as needed, or resign the signed .debs that are on the
    app store
[2] currently dpkg-sig is in Perl, which is a dependency we're trying to
    avoid for the SDK
Loïc Minier

Follow ups