ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

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.