Item Reviewed
| Android Service Based Installer | |||||||||
| Target |
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%); |
||||||||
{{#set:SecReview name=Android Service Based Installer
|SecReview target=
| ID | Summary | Priority | Status |
|---|---|---|---|
| 786380 | Write new Android service-based updater | -- | VERIFIED |
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);
}}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- New updater for Android based Firefox
- The old updater was hooked into the normal native update system - some C++ and JS components (all the same infrastructure, but custom code to apply the update) - big drawback - we couldn't ever check or apply an update without the app running - This isn't great if nightly isn't your default browser (you might not run it much).
- we couldn't download in the backround with the old updater
- What changes between nightly / aurora and beta / release? We still send update pings to get ADUs - mozupdater = 0 in config files.
- If mozupdater is disabled, the new updater won't be running either - so there are changes that could plausibly affect beta / release but it's unlikely.
- Releng
- SSL cert checking - relies on underlying android features. No authenticity check on the package - we're relying on a hash and a valid SSL cert to make sure everything else is OK.
What solutions/approaches were considered other than the proposed solution?
`
Why was this solution chosen?
`
Any security threats already considered in the design and why?
- We've had issues reported for the su issue on rooted phones... No longer a problem - all removed now.
Threat Brainstorming
- Can we think about scenarios where people aren't using Play and aren't getting updates?
- Can we capture this information?
- Do we want to solve this problem? (maybe we can't get this information)
- How about package signing?
{{#set: SecReview feature goal=*New updater for Android based Firefox
- The old updater was hooked into the normal native update system - some C++ and JS components (all the same infrastructure, but custom code to apply the update) - big drawback - we couldn't ever check or apply an update without the app running - This isn't great if nightly isn't your default browser (you might not run it much).
- we couldn't download in the backround with the old updater
- What changes between nightly / aurora and beta / release? We still send update pings to get ADUs - mozupdater = 0 in config files.
- If mozupdater is disabled, the new updater won't be running either - so there are changes that could plausibly affect beta / release but it's unlikely.
- Releng
- SSL cert checking - relies on underlying android features. No authenticity check on the package - we're relying on a hash and a valid SSL cert to make sure everything else is OK.
|SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=*We've had issues reported for the su issue on rooted phones... No longer a problem - all removed now. |SecReview threat brainstorming=*Can we think about scenarios where people aren't using Play and aren't getting updates?
- Can we capture this information?
- Do we want to solve this problem? (maybe we can't get this information)
- How about package signing?
}}
Action Items
| Action Item Status | In Progress |
| Release Target | ` |
| Action Items | |
| * snorp::Check to see if the app store is installed in the device - warn the user if they don't have the ability to get updates::
Bugzilla query errorQuery options must be valid JSON.1 |
|
{{#set:|SecReview action item status=In Progress
|Feature version=` |SecReview action items=* snorp::Check to see if the app store is installed in the device - warn the user if they don't have the ability to get updates::
Bugzilla query error
Query options must be valid JSON.1
}}