ubuntu-appstore-developers team mailing list archive

[David Pitkin <david.pitkin@xxxxxxxxxxxxx>]

We should think about how we would enable a service like TestFlight on our
platform, not a hard requirement for launch but at a later date. Also
Google just announced staged rollouts to App releases so that developers
can slowly roll out a release and watch for crashes.

http://stackoverflow.com/questions/4973244/how-does-testflight-do-it





On Thu, Jun 6, 2013 at 2:45 PM, Marc Deslauriers <
marc.deslauriers@xxxxxxxxxxxxx> wrote:

> On 13-06-06 02:19 PM, Loïc Minier wrote:
> > 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  :-)
>
> OK, fair enough.
>
> >
> >> 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
>
> I'd rather we simply not allow this. If we do allow it, I fear it's
> going to be an attack vector. If you want to push an update, you go
> through the app store.
>
> >
> >> 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?
>
> You want developers to be able to distribute a beta version of their app
> that didn't go through the app store approval process? I don't think we
> should allow that. It's a pretty big loophole. If we want developers to
> be able to do that, we should offer them a way to do it officially
> through the app store which we control and that users trust.
>
> >
> >>>  * 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.
>
> Sure, local developers push their cert to the device via the tethered
> development tools. Users gets betas through the official app store.
>
> As soon as we allow side loading of apps through means we don't control,
> even if it's by developers, we expose our users to risks we can't fix.
>
> >
> >> 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)
> >
>
> Again, we shouldn't give developers the opportunity of installing apps
> on user devices without going through our approval process. Once we do
> that, we lose control, and we lose user's trust in the 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
>