ubuntu-appstore-developers team mailing list archive

[Loïc Minier <loic.minier@xxxxxxxxxxxxx>]

On Thu, Jun 06, 2013, Marc Deslauriers wrote:
> >  * they might want to install apps manually instead of visiting an
> >    appstore; for instance this could be the way developers test their
> >    own apps before submitting them or when developing updates, this
> >    could be a way to get some beta-testing from developers directly to
> >    the users, or a way for users to install apps that have been removed
> >    from the appstore
> >    - depending on the implementation, we might be able to verify
> >      signatures of manually installed packages or not
> >    - we obviously must reject any unsigned or untrusted package by
> >      default
> 
> If we allow a user to enter an "insecure" mode where they can install
> arbitrary packages, what is the value in requiring them to be signed? A
> user is definitely not in a position to verify signature fingerprints
> and make security-conscious decisions based on the package signature.
> 
> For developers, they could either enter "insecure" mode, or perhaps they
> could side load applications via the host's debugging tools.

I'd rather have means for developers not to use insecure mode.  Both
because developers should be valued as first-class citizens and because
they are a high-value target  :-)

> I believe the apps installed in this way need to have been available in
> the app store for that to work. In the case of a developer, I believe
> XCode adds the developer signature (signed by apple) to the device when
> installing the app.

(Yup, I think this is similar to what I propose)

> > Similary on Android you can update an installed package with an .apk;
> > I've noticed that it checks that the key used to sign the package is the
> > same as the one that was used to sign the currently installed package,
> > but I'm not sure what other checks are in place.
> 
> Hrm, not quite sure about that one. That would allow application
> developers to bypass the app store restrictions, wouldn't it?

Good question; no idea

> > So you have a point that we'd need some *appstore* trust path on top of
> > the developer signature in the package, but this goes against one of the
> > fundamental assumptions we were taking until now: that the package is
> > untouched from the developer.
> 
> I don't think the appstore trust path should touch the package. When you
> install an app from the appstore, the appstore gives you the package,
> plus a hash of the package signed with the appstore key.

Ok; I also prefer if the appstore doesn't touch the package and only
signs the indices.

> > Still, we would at least want to allow developers to deploy apps to
> > their own device for testing, preferably without disabling security
> > entirely.
> > 
> > Would it work to combine signed indices with developer keys?  e.g.:
> >  * by default, users can only install apps which are listed in the
> >    official appstore (signed) index
> >  * when they do, this gets the developer key from the appstore and
> >    verifies the package against the index hash and the developer
> >    signature
> 
> Why check the developer signature? As long as the app store signature
> matches, and the hash matches, it's fine.

This is to match the checks done when installing a package locally
(which are to just check the package against the developer key).

> We _could_ have a fallback if we want where if the package doesn't have
> a matching hash in the app store directory, we check the package
> signature with a cert in a well-known system location that can be only
> put there by the developer tools.

Right, something like that

> >  * users may install updates of installed packages /signed with the same
> >    developer key/ by other means
> 
> This allows a malicious developer to publish an harmless fart app in the
> store, which auto-updates itself with a malicious version.

Hmm only if there's an app-installation API; even if we had one, we
could display warnings at this point

> This could also be used by developers to get around restrictions we may
> have in our app store.
> I don't think we should allow this. All packages that can be installed
> on the device in "safe" mode should go through the store.

Well, the point would be to allow testing new versions of an app,
potentially with added permissions.

I guess another way would be for the appstore to feature beta versions;
do you see other means?

> >  * don't think we want this: users may turn off any verification and
> >    install untrusted packages
> 
> Although this sounds bad, I don't think there's a difference between
> untrusted and package with arbitrary signature. I think once you enable
> the "insecure" mode, you can do as you wish.

What would be bad is if the default system is so locked that many people
disable security entirely; I prefer we try to offer answers for the
common cases (e.g. local developers, publishing betas etc.) to avoid it.

> Do we really want that? (except for developers, or "insecure" mode)?

(I guess it's the same problem as above)

> > Something related we had discussed yesterday is how do we namespace apps
> > and prevent squatting names (e.g. how do you prevent someone to take
> > "myapp" as appname, or if you are the one owning com.ubuntu.phone, how
> > do you prevent someone from using the same app name or naming things
> > under your realm).
> >   I mention this because I think that even if we allow local
> > installation of apps for e.g. developers, we would want to prevent
> > replacing an official app with a locally built app with the same name.
> > (We excluded GUIDs because these are ugly in the filesystem for the
> > convergence case.)
> > 
> 
> Oh? Why? Don't you want a developer to be able to test his new version?
> Don't you want a hobbyist to be able to build a custom version of the
> media player?

I guess it's ok if we can force this to be local, but it wouldn't be ok
if developer x could hand a file to user y signed with his key that
would replace an official app.  (I guess it's kind of obvious)

-- 
Loïc Minier