ubuntu-appstore-developers team mailing list archive

[David Pitkin <david.pitkin@xxxxxxxxxxxxx>]

Marc I think there is one other thing which is that the app being submitted
to the store actually game from the developer. This is an important thing
and simply a login is mostly insufficient from a strong security
perspective which is why developers have been signing apps even if its
somewhat painful.

David

On Thu, Jun 6, 2013 at 10:27 AM, Marc Deslauriers <
marc.deslauriers@xxxxxxxxxxxxx> wrote:

> 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.
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-appstore-developers
> Post to     : ubuntu-appstore-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers
> More help   : https://help.launchpad.net/ListHelp
>