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