Provide mechanism to provision phones with an additional certificate for testing

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
5 years ago
2 years ago

People

(Reporter: ozten, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Background: A new project BetaFox[1] was relying on the same provisioning steps as the old "Installing Reviewer Certs"[2] procedure. This has been removed from FxOS and those certs are now baked into the device, eliminating the capability to add additional certs via adb.

Requirements:
* BetaFox is a self-hosted service which allows developers to distributed privileged apps for testing, before entering the Marketplace review queue
* Some mechanism which allows a user to provision a device as a beta testing device which trusts a deployed instance of BetaFox software
* A provisioned device should allow install of a privileged packaged app via the mozApps.installPackage API
* A provisioned device should launch installed privileged packaged apps signed by a BetaFox service
* A partner could self-host a BetaFox instance behind a corporate firewall
* A partner can generate their own certificate

Related Marketplace reviewer bugs: bug#896620 bug#1021345

[1] https://wiki.mozilla.org/Mobile/Projects/BetaFox
[2] https://wiki.mozilla.org/Marketplace/Reviewers/Apps/InstallingReviewerCerts
(Reporter)

Updated

5 years ago
Blocks: 1004611
Flags: needinfo?(dkeeler)
Here's my understanding of the current consensus for how to go about this:

* Modify AppTrustDomain to handle additional specified trusted roots (in addition to those already built in)
* Modify Webapps.jsm to pick the appropriate root given that the user may have installed additional root certificate/install origin pairs
* Add UI for users to import and trust a root certificate for a given app install origin

I believe this would fulfill all requirements (and in particular the final one, that partners have the ability to generate their own certificates).

I'd like to propose an alternative that would be significantly less complex, require fewer implementation changes, and would be more likely to ship earlier. Instead of adding new roots (and implementing a UI to manage them), let's have all such development work use a single signing certificate with a well-known private key. All that would be necessary at that point would be to associate a development app install origin (or set of origins) with the well-known test root. This could be a string pref, which would make UI much simpler. Only when in development mode and only when the app install origin matches a specified origin would an app signed by this root verify correctly. All other app verification would work as expected.
I realize asking people to use a publicly-known private root seems strange, but unless I'm misunderstanding the use-cases, the guarantees/benefits from proper signing don't really apply here.
Flags: needinfo?(dkeeler)
(Reporter)

Comment 2

5 years ago
> I'd like to propose an alternative that would be significantly less complex...

To restate this, to make sure I understand

* A new well known signing certificate would be created
* It's private key can be distributed to partners for installation on their app server
* If devices must be in development mode
* If preference must be set which includes the app server's endpoint as a trusted install origin
* Then device trusts configured 3rd party app server while still working with production Marketplace
* and optionally Marketplace review could also be enabled
(In reply to Austin King [:ozten] from comment #2)
> To restate this, to make sure I understand

Yes, I think we're on the same page.

> * and optionally Marketplace review could also be enabled

We could make these separate, if need be. The way I was thinking, they would both be enabled if the development mode was enabled.
(Reporter)

Comment 4

5 years ago
If it isn't a substantial burden...

It would be ideal that we could have a device trust multiple certificates.

Use Case: I provision my phone to trust BetaFox, but it still allows me to install and launch apps signed by the marketplace.

Reasoning - This will allow community members to beta test on their main phone, without a dedicated "testing" phone.
Sure - I think a good approach would be to basically have a map of domain -> root certificate. marketplace.firefox.com would map to the root currently in use, marketplace-dev.allizom.org would map to the dev root in use, and testers/developers could add their own mapping of foocorp.example.com -> {foocorp certificate}. These should all be able to coexist without affecting installation from different domains.
(In reply to David Keeler (:keeler) [use needinfo?] from comment #5)
> Sure - I think a good approach would be to basically have a map of domain ->
> root certificate. marketplace.firefox.com would map to the root currently in
> use, marketplace-dev.allizom.org would map to the dev root in use, and
> testers/developers could add their own mapping of foocorp.example.com ->
> {foocorp certificate}. These should all be able to coexist without affecting
> installation from different domains.

Yes, we'll definitely need that kind of flexibility.
Created attachment 8465065 [details] [diff] [review]
bug-1023499.patch

Quick hack of a patch attached, which adds provisions for a new "DevTest" root.  The idea is: 
* We publish the cert AND the private key that goes with it
* Developers could then sign their apps with the private key
* Developers/testers use some UI to enable the test root for a specific origin

With this patch, it seems like it should be possible to adapt the _openSignedPackage method in Webapps.jsm (which already changes the root used for verification) to enable the test root for specific origins.

Still TODO: Figure out when apps should be verified with the test cert, and how to prevent this from becoming a huge security hole.  Also, tests.

Austin, Fabrice: Does this look like a reasonable starting point?
Flags: needinfo?(ozten.bugs)
Flags: needinfo?(fabrice)
(Reporter)

Comment 8

4 years ago
With the given caveats, this LGTM.

We should make it built in to:

* Authorize betachannel.mozilla.org to use DevTest

We should make it possible to:

* Add additional origins as "Distribution Channels" which would also use DevTest

These points are mentioned in Bug#1012705
Blocks: 1012705
That sounds reasonable to me. I can help with the Webapps.jsm changes if needed.
Flags: needinfo?(fabrice)
Great.  I'm going to consider my work here done for the moment :)

Please circle back once you guys have an idea of how you're going to enable use of DevTest.  I'm very concerned about this being a vector for circumventing app signing.  I would be glad to review patches.
Flags: needinfo?(ozten.bugs)
Is this still needed?
Flags: needinfo?(ozten.bugs)
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.