1284582 - Sign Stub Mobile Installer with official Fennec key for demo of our Distribution capability

Status: RESOLVED WONTFIX

(Release Engineering :: Release Requests, defect)

Description

[Mike Kaply [:mkaply]]

Attachment: Bouncer based on Firefox beta.

The mobile team has built a new distribution mechanism that involves creating a stub application (bouncer) that lays down some distribution customizations and then redirects the user to the play store to download Firefox.

It works by using the same app name and signature as a regular Firefox or Firefox Beta build so that it looks like an upgrade.

We'd like to demo this functionality to some partners, but in order to do that, we need our demo bouncer to be signed in a similar way.

I've attached it to this bug. It's based on Firefox Beta.

Going forward, we're going to be doing these for our partners, so we'll need to investigate some way to automate this process.

To be clear, these builds will never be on the store. Partners will either preload them on their devices or provide them as downloads from their websites.

Comment 1

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Mike Kaply [:mkaply] (Out June 27-July 5) from comment #0)
> We'd like to demo this functionality to some partners, but in order to do
> that, we need our demo bouncer to be signed in a similar way.

Does this mean that we need to use the same process or the same signing key? What are the requirements?

What is the state of the demo bouncer? Is this demo quality code (sounds like it from the description above)?

Comment 2

[Mike Kaply [:mkaply]]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #1)
> (In reply to Mike Kaply [:mkaply] (Out June 27-July 5) from comment #0)
> > We'd like to demo this functionality to some partners, but in order to do
> > that, we need our demo bouncer to be signed in a similar way.
> 
> Does this mean that we need to use the same process or the same signing key?
> What are the requirements?

It needs to be the same signing key.

If you want to build it, that's not a problem for me (and is probably the correct thing). It involves setting up a directory with the distribution information and then adding an additional line to .mozconfig.

ac_add_options --with-android-distribution-directory=/location/of/partner/assets/dir

Then the bouncer.apk is built as part of the packaging step.

> 
> What is the state of the demo bouncer? Is this demo quality code (sounds
> like it from the description above)?

The thing that makes it a demo is the choice of the content (demo bookmarks, homepage)

The bouncer itself is release quality and is a part of the Firefox 48 build.

Comment 3

[Mike Kaply [:mkaply]]

The original bug that created the bouncer/stub installer:

https://bugzilla.mozilla.org/show_bug.cgi?id=1234629

Some documentation on the bouncer:

http://gecko.readthedocs.io/en/latest/mobile/android/fennec/bouncer.html

Comment 4

[Jordan Lund (:jlund)]

(In reply to Mike Kaply [:mkaply] (Out June 27-July 5) from comment #0)
> Created attachment 8768102 [details]
> Bouncer based on Firefox beta.

> Going forward, we're going to be doing these for our partners, so we'll need
> to investigate some way to automate this process.

cool. this would be great to automate so we don't sign out of infra going forward.

(In reply to Mike Kaply [:mkaply] (Out June 27-July 5) from comment #2)

> > Does this mean that we need to use the same process or the same signing key?
> > What are the requirements?
> 
> It needs to be the same signing key.
> 
> If you want to build it, that's not a problem for me (and is probably the
> correct thing). It involves setting up a directory with the distribution
> information and then adding an additional line to .mozconfig.

as mentioned above, I think having releng setup infra so this is built in automation it is the right approach going forward. However, integrating this is > 1 day job with a likely long tail of questions like how often do we build, where do we build, will this ride trains, can this be a CI job with release key or do we want it to be more like a partner based release in parallel to Firefox releases, do we need updates, how dynamic do we want the partner assets dir path to be, etc.

So given that, and mentioned in #release-drivers, IMO, the question today is: are we willing to sign the apk already built and handed to releng via email for the upcoming demo via remco's phone?

if yes, I'll sign it and send back via email. if no, we can't support this upcoming demo and instead wait until we have integrated automation. rel-man's call. lizzard?

Comment 5

[Jordan Lund (:jlund)]

(In reply to Jordan Lund (:jlund) from comment #4)

> However, integrating this is > 1 day job with a likely long tail of questions like:

just to document more questions so I don't forget to ask at the time: can this automation wait for taskcluster support as opposed to buildbot?

pros to this: #mobile would have more 'self serve' control where you can schedule, define, and sign these builds as you please. Even better, you can extend this with other android variants.

downsides to this: Taskcluster support for this would likely be end of Q3. we currently build+release android ff builds through buildbot still and we don't have support for signing/updates yet in TC[1].

[1] https://bugzilla.mozilla.org/showdependencytree.cgi?id=1118394&hide_resolved=1

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

I think we had a lot of good discussion on the email thread about this and thanks to everyone for the details. I am still opposed to signing something with our official key that doesn't go through our normal build and release infrastructure. I respect the development work here and think it sound like a reasonable plan. But the concept of signing the build means we are committing the millions of users we already have, to trust this build. I have to take the conservative stance even if this is just for a single demo.

This is something we should plan with normal releng work. This sounds like the beginnings of a plan. We can do that over time, but for a demo that we need *today* we will need to work something else out that doesn't involve signing an unofficial build.

Comment 7

[Jordan Lund (:jlund)]

(In reply to Mike Kaply [:mkaply] from comment #2)

> If you want to build it, that's not a problem for me (and is probably the
> correct thing). It involves setting up a directory with the distribution
> information and then adding an additional line to .mozconfig.

nthomas raised an idea here. I'll try to paraphrase. How about we build this in Taskcluster automation on try. this bouncer.apk sounds like an artifact from something like the partner sample android variant we have already: https://treeherder.mozilla.org/logviewer.html#?job_id=23450703&repo=try#L2358

So basically, you schedule and run this on try as you want. maybe tweaking the task def[1] or mozconfig/asset path[2] as you need. If you need this to be based on mozilla-beta, I believe you can push a beta rev to try and have the taskcluster decision task still treat your repo as a try push, scheduling builds based on it.

then you could point us to your try push url and we could take the apk from the uploaded artifacts rather than taking something built outside and uploaded in email. It's still not the most secure of things but at least the cset diff, logging, and automation all ran in our infra. It might just strike a balance of risk mgmt on release side of things and not having to depend heavily on our infra integration/setup on your mobile end.

mkaply, nick: maybe one of you could tweak this build to do what you need in TC? 

liz, what do you think?

[1] https://dxr.mozilla.org/mozilla-central/source/taskcluster/ci/legacy/tasks/builds/android_api_15_partner_sample1.yml
[2] https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/builds/releng_sub_android_configs/64_api_15_partner_sample1.py#6

Comment 8

[Jordan Lund (:jlund)]

(In reply to Jordan Lund (:jlund) from comment #7)

> mkaply, nick: maybe one of you could tweak this build to do what you need in
> TC? 

two nicks (and now a pun to boot) mentioned in last comment. in the line above, I meant nick alexander, not thomas

Comment 9

[Nick Alexander :nalexander [he/him]]

(In reply to Jordan Lund (:jlund) from comment #8)
> (In reply to Jordan Lund (:jlund) from comment #7)
> 
> > mkaply, nick: maybe one of you could tweak this build to do what you need in
> > TC? 
> 
> two nicks (and now a pun to boot) mentioned in last comment. in the line
> above, I meant nick alexander, not thomas

My intention was always that we make the demo-partner-build TC task the way to produce these APKs, although that doesn't handle the Play Store problem.

I will not get to this anytime soon, however: I'm committed to Tofino for the foreseeable future.  I think mkaply will find this challenging to move on, although with mcomella's help he may find success.  We'd mostly want to get the partner builds running, from which all changes can flow.  Perhaps jlund can make sure this get scheduled (once a day?) once he's done with TC Android Tier 1?

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

I'm planning ot meet with Barbara and mkaply this week, we could also invite dveditz into that discussion.  Basically, I would like sec team input.

Comment 11

[Mike Kaply [:mkaply]]

I've opened a separate bug to start this process, bug 1286944.

I'm going to WONTFIX this bug, since we aren't signing this specific thing.