Closed Bug 794213 Opened 12 years ago Closed 11 years ago

Need signing certificates for B2G FOTA updates

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Platform:
x86_64
Linux
Type:
defect

Tracking

(blocking-b2g:-, blocking-basecamp:-, b2g18 affected, b2g18-v1.0.0 affected, b2g18-v1.0.1 affected)

Status:
RESOLVED WONTFIX
Milestone:
B2G C4 (2jan on)
Project Flags:
blocking-b2g -
blocking-basecamp -
Tracking Flags:
Tracking Status
b2g18 --- affected
b2g18-v1.0.0 --- affected
b2g18-v1.0.1 --- affected

People

(Reporter: overholt, Assigned: schien)

References

Details

(Whiteboard: [waiting on partner info (1/2)] [NPOTB] [Triaged:1/17]) 

To be able to verify update signatures, we'll need the certificates.  Marshall Culpepper or Brian Smith are good recipients of these certificates.

We'll need:

- nightly certificate
- test OEM and carrier certificates
Priority: -- → P3
Is this still an issue?
Flags: needinfo?(catlee)
blocking-basecamp: ? → +
Summary: Need signing certificates for B2G updates → Need signing certificates for B2G FOTA updates
Wait, what is the bug about? Certs used for FOTA updates, right? We're not doing Gecko/Gaia updates for v1, right?
Certs for gecko updates are in https://bugzilla.mozilla.org/attachment.cgi?id=679427 in case we need them.
Flags: needinfo?(catlee)
Can we get an answer :bsmith 's question in Comment 2? Please?  Let's get this closed out if not needed.
(In reply to Brian Smith (:bsmith) from comment #2)
> Wait, what is the bug about? Certs used for FOTA updates, right? We're not
> doing Gecko/Gaia updates for v1, right?

I filed this after you and catlee and I discussed what we'd need for incremental updates :)  Perhaps it's no longer valid?
Flags: needinfo?(bsmith)
I haven't seen or heard anything that suggests we aren't doing Gecko+Gaia apps for V1.  How else are we going to upgrade 1.0 devices?
Target Milestone: --- → B2G C3 (12dec-1jan)
I'm pretty cjones is in discussions with partners regarding this so let's wait for the outcome of that.
Flags: needinfo?(bsmith) → needinfo?(jones.chris.g)
Whiteboard: [waiting on partner info (1/2)]
Target Milestone: B2G C3 (12dec-1jan) → B2G C4 (2jan on)
After talking with SC, it looks like there has no further action required for this case. Chris, is it true? If yes, maybe we could close this case.
Flags: needinfo?(catlee)
The only thing to decide is if we want to use a separate key for the final release builds or not. But AIUI we're not shipping release binaries, so it probably doesn't matter.
Flags: needinfo?(catlee)
gal: This is not a blocker for basecamp. If we need a cert, we will update it after basecamp.
blocking-b2g: --- → tef+
blocking-basecamp: + → -
Flags: needinfo?(jones.chris.g)
cjones, can you provide info from your conversations with partners?  Do we still need this?
Assignee: catlee → jones.chris.g
Flags: needinfo?(jones.chris.g)
I still don't have an update.  If I did, I would have provided it.

But I've been out of some recent conversations due to language issues, so maybe khu has more recent info.
Flags: needinfo?(jones.chris.g) → needinfo?(khu)
since the build system for FOTA package is in the partner's site, we don't have to obtain signing certificates from the partner.
Flags: needinfo?(khu) → needinfo?
More specifically, we need to reach a final agreement on gecko/gaia updates.  If we'll be distributing those, we need to create a certificate for testing.
Flags: needinfo?
(In reply to Chris AtLee [:catlee] from comment #9)
> The only thing to decide is if we want to use a separate key for the final
> release builds or not. But AIUI we're not shipping release binaries, so it
> probably doesn't matter.

1. My understanding is that we will sign the FOTA updates and Gecko/Gaia updates of development builds that Mozilla distributes. What channels will we have for FOTA and/or Gecko/Gaia updates? i.e. will we have "central," "aurora," "beta," and "release" like Firefox? Is it OK to use the same key for these that is used for Nightly/Aurora signing of Firefox?

(In reply to khu from comment #13)
> since the build system for FOTA package is in the partner's site, we don't
> have to obtain signing certificates from the partner.

2. We can configure our build system so that the build configuration chooses which certificate to use. Then, when Mozilla builds things, it will need to configure the build to use Mozilla's certificate, and when an OEM builds things, it will need to configure the build to use its own certificate. So, it is technically true that we don't really need the partners' certificates.

However, my understanding is that at least one partner has told Mozilla "Here is a server, you set up that server so that it can serve the FOTA updates and we'll run it." Because of that, we still need to work with that partner as far as configuring that server with the right key and certificate.
Thanks for Brian's information. 

Shih-Chiang(schien) is playing as a technical contact and working with one China partner to setup the FOTA server recently. Schien is working on step-by-step guideline for the partner and he might have better understanding here.
Whiteboard: [waiting on partner info (1/2)] → [waiting on partner info (1/2)] [NPOTB] [Triaged:1/17]
Assignee: jones.chris.g → schien
TEF?
Since this is not part of the build, and is being worked on separately with partner. 
TEF+ is probably not a good way to tracking since this is not part of the delivery we need to make in the upcoming days
blocking-b2g: tef+ → tef?
Can remain as tef+, since it's already marked as NPOTB. Understood that this not necessarily going to be resolved in the short term.
blocking-b2g: tef? → tef+
Is someone working on getting a certificate into the tree or will partners insert their own certs into the builds they produce?
(In reply to Andrew Overholt [:overholt] from comment #19)
> Is someone working on getting a certificate into the tree or will partners
> insert their own certs into the builds they produce?
Since partners are willing to manage the FOTA server by themselves, it's most likely that partner will insert their own certs into the builds they produce. I'll confirm with partners.
(In reply to Shih-Chiang Chien [:schien] from comment #20)
> (In reply to Andrew Overholt [:overholt] from comment #19)
> > Is someone working on getting a certificate into the tree or will partners
> > insert their own certs into the builds they produce?
> Since partners are willing to manage the FOTA server by themselves, it's
> most likely that partner will insert their own certs into the builds they
> produce. I'll confirm with partners.

Okay, we can likely close this when we have that confirmation.  Thanks.
Flags: needinfo?(schien)
I am working on adding a .userconfig option for the OEM to set the path to the signing certificate.

For internal B2G builds, I will use the same certificates that Firefox Desktop Nightly/Aurora/Beta/Release use. For example, nightly builds of B2G should (eventually) only accept MAR files signed using the same key used to sign Firefox Desktop Nightly builds, etc.
According to the latest response from parter, they'll put the certs for FOTA update in recovery image by themselves.
Flags: needinfo?(schien)
As we are working with many other partners (i.e. Geeksphone, and others...) how can we involve them in this discussion?
Shih-Chiang, is it possible to make the work you've been doing generic so other partners can re-use it as much as possible?
(In reply to Andrew Overholt [:overholt] from comment #25)
> Shih-Chiang, is it possible to make the work you've been doing generic so
> other partners can re-use it as much as possible?
You mean the guideline for setting up FOTA system? Sure, I can publish it on wiki.
(In reply to Shih-Chiang Chien [:schien] from comment #26)
> (In reply to Andrew Overholt [:overholt] from comment #25)
> > Shih-Chiang, is it possible to make the work you've been doing generic so
> > other partners can re-use it as much as possible?
> You mean the guideline for setting up FOTA system? Sure, I can publish it on
> wiki.

Awesome, thanks.
Lucas - this bug is currently marked as NPOTB. Is that still true? Perhaps we should remove this entirely from the list, since our expectation is that this won't land in our source trees.
Flags: needinfo?(ladamski)
I'd like to keep this open if for no other reason than to make sure we verify the FOTA mechanism with the production devices/certs.
Flags: needinfo?(ladamski)
This bug shouldn't be considered NPOTB because the signing certificates *are* needed as part of the build. However, my plan is to use the same certs as Firefox, for mozilla-hosted updates. So, as long as we're cool with that, then this bug is already FIXED. If we want to use different certs for FirefoxOS and Firefox, then this bug isn't fixed and we need the certs to use for FirefoxOS. However, IMO, it is reasonable to use the same certs as Firefox and also simpler.

FWIW, I am working on making the key easily customizable in B2G as part of bug 797477.
(In reply to Brian Smith (:bsmith) from comment #30)
> FWIW, I am working on making the key easily customizable in B2G as part of
> bug 797477.

Sorry, to be precise: I am working on making it so that each OEM can customize the build to substitute its own certificate from .userconfig as part of bug 797477.
Batch edit: Bugs marked status-b2g18: affected after 2/13 branching of v1.0.1 are now also status-b2g18-v1.0.1: affected
status-b2g18-v1.0.1: --- → affected
(In reply to Brian Smith (:bsmith) from comment #30)
> This bug shouldn't be considered NPOTB because the signing certificates
> *are* needed as part of the build. However, my plan is to use the same certs
> as Firefox, for mozilla-hosted updates. So, as long as we're cool with that,
> then this bug is already FIXED. If we want to use different certs for
> FirefoxOS and Firefox, then this bug isn't fixed and we need the certs to
> use for FirefoxOS. However, IMO, it is reasonable to use the same certs as
> Firefox and also simpler.

Let's consider this already fixed in that case (unless joduinn disagrees) - our partners can customize their cert as necessary.
blocking-b2g: tef+ → -
Flags: needinfo?(joduinn)
(In reply to Alex Keybl [:akeybl] from comment #33)
> (In reply to Brian Smith (:bsmith) from comment #30)
> > This bug shouldn't be considered NPOTB because the signing certificates
> > *are* needed as part of the build. However, my plan is to use the same certs
> > as Firefox, for mozilla-hosted updates. So, as long as we're cool with that,
> > then this bug is already FIXED. If we want to use different certs for
> > FirefoxOS and Firefox, then this bug isn't fixed and we need the certs to
> > use for FirefoxOS. However, IMO, it is reasonable to use the same certs as
> > Firefox and also simpler.
> 
> Let's consider this already fixed in that case (unless joduinn disagrees) -
> our partners can customize their cert as necessary.

1) Mozilla does not generate any FOTA updates.

2) Mozilla does generate OTA (not FOTA) updates. Note that we disabled the signing of OTA updates based on decisions made in Madrid workweek to drop signing of updates. https://bugzilla.mozilla.org/show_bug.cgi?id=797477#c79

3) Partners would be generating their own updates. If interested in signing, partners would sign their own updates, using their own keys. No concern about having to share any existing or future Firefox keys with partners.

I think this is WONTFIX/RESO-INCOMPLETE because there's no need to setup up any signing here. Anything I'm missing?
Flags: needinfo?(joduinn)
(In reply to John O'Duinn [:joduinn] from comment #34)
> (In reply to Alex Keybl [:akeybl] from comment #33)
> > (In reply to Brian Smith (:bsmith) from comment #30)
> > > This bug shouldn't be considered NPOTB because the signing certificates
> > > *are* needed as part of the build. However, my plan is to use the same certs
> > > as Firefox, for mozilla-hosted updates. So, as long as we're cool with that,
> > > then this bug is already FIXED. If we want to use different certs for
> > > FirefoxOS and Firefox, then this bug isn't fixed and we need the certs to
> > > use for FirefoxOS. However, IMO, it is reasonable to use the same certs as
> > > Firefox and also simpler.
> > 
> > Let's consider this already fixed in that case (unless joduinn disagrees) -
> > our partners can customize their cert as necessary.
> 
> 1) Mozilla does not generate any FOTA updates.
> 
> 2) Mozilla does generate OTA (not FOTA) updates. Note that we disabled the
> signing of OTA updates based on decisions made in Madrid workweek to drop
> signing of updates. https://bugzilla.mozilla.org/show_bug.cgi?id=797477#c79
> 
> 3) Partners would be generating their own updates. If interested in signing,
> partners would sign their own updates, using their own keys. No concern
> about having to share any existing or future Firefox keys with partners.
> 
> I think this is WONTFIX/RESO-INCOMPLETE because there's no need to setup up
> any signing here. Anything I'm missing?

No reply to this for a couple of months. I'm going to assume that John is correct.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.