ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

Hi!

On 13-06-05 11:39 AM, Loïc Minier wrote:
>         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 actually two different things here:
- Guaranteeing that the app actually came from the developer
- Guaranteeing that the app actually came from the trusted app store

> 
> 
> 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
> 
> or
> 
> 2. signature is embedded in the package at build time (developer
>    workstation) and verified on the client[1]

I think you're missing the most important scenario:

3. signature is on a package list which contains a crypto hash of each
individual package.


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

Actually, it's of the third type. We distribute .deb packages over http,
not over a secure transport.

Mobile devices typically have the application author sign his package,
which is then hosted in the official app store using approach #3.

On iOS, you can't load packages that don't come from the trusted store
(with a few exceptions, for example, if you obtain an enterprise cert
from apple for homemade apps)

On Android, you can't load packages that don't come from the trusted
store _unless_ you go into the settings and specifically check the box
to enable installing untrusted apps after clicking through a warning.
Many carriers disable this option.

If you can install applications without going through a trusted app
store, you become vulnerable to malware and security issues.

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

Yes, especially on mobile devices where you cannot easily push out an
update to blacklist compromised CAs.

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

This is only to ensure that the package comes from a particular
developer, not to indicate if a package is from a trusted app store.

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

I hope we're talking about an android-type option targeted mainly at
developers. I definitely wouldn't want regular users to be able to
install untrusted packages from a web page by default. There is no way
for us to maintain a device with a level of security comparable to iOS
or default Android if we allow doing that.

> 
>     Cheers,
> 
> [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

We shouldn't require devices to validate developer signatures. There's
no easy way of knowing which developer is trusted, and no easy way of
updating those keys. Devices should simply validate the signature on the
hash given by the official app store.


Marc.