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 -- 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
