Closed Bug 1151537 Opened 10 years ago Closed 10 years ago

Support hotfixes in the new signing requirements

Categories

(Toolkit :: Add-ons Manager, defect, P1)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Points:
2

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla40
Iteration:
40.3 - 11 May
Tracking Flags:
Tracking Status
firefox39 --- wontfix
firefox40 --- verified

People

(Reporter: mossop, Assigned: mossop)

References

Details

(Whiteboard: [fxsearch][searchhijacking])

Attachments

(3 files)

patch
(deleted), patch
dveditz
: review+
robert.strong.bugs
: review+
Details | Diff | Splinter Review
test-hotfixes.zip
(deleted), application/zip
Details
test-hotfixes-4042-signed.zip
(deleted), application/zip
Details 
Hotfixes are currently required to be signed by a fixed signing certificate that we periodically upgrade. When Firefox transitions to requiring all add-ons be signed by a cert that chains to our AMO root the hotfix will no longer work. We need to fix that.

Options on the table:

1. Make the hotfix add-on exempt from the new requirements and continue using the current system of a custom signing cert. This would require exemption handling in both Firefox and AMO so the hotfix doesn't get re-signed on upload.

2. Switch to using the new system, the hotfix will get signed by AMO on upload just like every other add-on and Firefox will check the ID matches on download. We have to trust that hackers can't upload their own add-on with the hotfix ID to AMO somehow. No AMO work here, Firefox will have to have minimal work to avoid the current custom cert checks.

3. Use a hybrid system, generate a fixed signing cert from the AMO root and embed its fingerprint into Firefox and always sign the hotfix with that. Minimal changes to Firefox should be necessary for that, AMO will have to exempt the hotfix from the auto-signing system.
I'd prefer #3. I'm not even sure it would require an exemption, so much as allowing XPIs that are signed by a cert in the AMO root's chain.

I would definitely like to avoid #2. There are too many ways someone could get access to upload a new version of the hotfix add-on to AMO. Even if we were to add specific protections to the listing, I still wouldn't be happy with dropping the requirement that it be signed through a separate process.
It seems that Thunderbird doesn't intend on turning on the new signature requirements and they also have a hotfix on AMO so there may still need to be some work to support that case
I guess we could simply add the firefox hotfix add-on ID to our settings, and then not sign it (on submission and in scripts).

Do you confirm that the ID is 354399? Are there any other add-ons we need to exempt?
Not much stake here for RelEng. If we go with #3 we could look at having Jorge and co. do hotfix signing since it won't require access to a private key that's shared with Authenticode signing at that point. That would probably speed up testing and delivery of hotfixes.
(In reply to Ben Hearsum [:bhearsum] from comment #4)
> Not much stake here for RelEng. If we go with #3 we could look at having
> Jorge and co. do hotfix signing since it won't require access to a private
> key that's shared with Authenticode signing at that point. That would
> probably speed up testing and delivery of hotfixes.

We'll still need to retain the signing cert somewhere secure. I assume releng can do that already, maybe with the new signing stuff AMO can too?
(In reply to Mathieu Agopian [:magopian] from comment #3)
> I guess we could simply add the firefox hotfix add-on ID to our settings,
> and then not sign it (on submission and in scripts).
> 
> Do you confirm that the ID is 354399? Are there any other add-ons we need to
> exempt?

Firefox's is firefox-hotfix@mozilla.org. Thunderbird's seems to be thunderbird-hotfix@mozilla.org but it's not clear whether bug 914225 is actually done or not yet.
(In reply to Dave Townsend [:mossop] from comment #5)
> (In reply to Ben Hearsum [:bhearsum] from comment #4)
> > Not much stake here for RelEng. If we go with #3 we could look at having
> > Jorge and co. do hotfix signing since it won't require access to a private
> > key that's shared with Authenticode signing at that point. That would
> > probably speed up testing and delivery of hotfixes.
> 
> We'll still need to retain the signing cert somewhere secure. I assume
> releng can do that already, maybe with the new signing stuff AMO can too?

Sure, we can. But if it's just a cert off the AMO root (which I assume we have access to), I assumed the AMO folks could put it near the AMO root. Assuming that's true, adding RelEng into the process just adds extra handoffs and delays, I think.

In any case, we can figure that part out later if we go this route.
We already have special cases for the Firefox hotfix in the update service. The add-on ID is hardcoded there, so it should probably be defined as a constant somewhere more reasonable. In any case, I'd rather rely on the add-on's internal ID than the listing ID.
I'd prefer that the hotfix signing still happen on the releng end. If we moved the signing to AMO, I think it would require an added layer of security (I'm not sure what that would look like), and some non-trivial engineering work to support the special case. Otherwise we essentially end up with option #2. I think the hotfix is too high value a target to leave at this.

If we chose to do it outside of AMO, as Dave says, we'd need somewhere secure to store the key and do the signing, and I don't know where that would be. I think releng is already the best equipped to handle this.
Did some more research here. With the code as-is in bug 1038068, option 3 is very simple from Firefox's side, we just need to update the certificate fingerprint we expect in prefs. Additionally if Thunderbird doesn't turn on signing requirements then it will just work and fall back to the old object signing just fine.

Option 1 is harder in Firefox. It would add some complexity to allow the code that automatically installs hotfixes to be exempt from the new requirements without making any add-on installed with the right ID exempt too.

So on that basis I'd prefer to go with option 3. There is a catch though, if we want to ship a hotfix that targets both Firefox before mandatory signing and after we would need to do so as two different XPIs, one signed with the old cert and one signed with the new. As long as they are two different versions I'm told that AMO should be able to handle that though we would want to do QA to check.
It seems like there is a strong push for option three. Any further concerns we havent discussed?
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Points: --- → 2
Flags: qe-verify+
Flags: firefox-backlog+
I just wanted to check, since I don't really know how this works, is it actually possible for us to generate a signing cert that we can then hold somewhere secure, whether that is releng or AMO based, to use to sign Firefox hotfixes in the future?
Flags: needinfo?(jthomas)
Flags: needinfo?(bhearsum)
Lawrence, just realised we don't have release management in here and as I noted in comment 10 the changes could cause us some extra work around releasing hotfixes during the transition. Do you have any concerns around that?
Flags: needinfo?(lmandel)
(In reply to Dave Townsend [:mossop] from comment #12)
> I just wanted to check, since I don't really know how this works, is it
> actually possible for us to generate a signing cert that we can then hold
> somewhere secure, whether that is releng or AMO based, to use to sign
> Firefox hotfixes in the future?

If we're talking about option #3, this certificate must be generated off of the AMO root. This probably means that someone needs to generate a private key + CSR, and then someone with access to the AMO root can generate a certificate from that CSR that's signed by the AMO root.

RelEng certainly has places that we can generate and store the private key + resulting cert, but I think it would be much better for the folks that stage hotfixes to take on signing at this point. The only reason RelEng has been involved up until now is because the hotfix signing cert was the same certificate we use for Windows Authenticode signing, so it couldn't be shared outside of RelEng. Now that we're talking about a cert off the AMO root, keeping RelEng in the process is just adding unnecessary handoffs to the process.
Flags: needinfo?(bhearsum)
(In reply to Dave Townsend [:mossop] from comment #12)
> I just wanted to check, since I don't really know how this works, is it
> actually possible for us to generate a signing cert that we can then hold
> somewhere secure, whether that is releng or AMO based, to use to sign
> Firefox hotfixes in the future?

We should be able generate a signing certificate off of the AMO Root. It is a offline certificate and requires coordination with OpSec.  CC'ing :kang
Flags: needinfo?(jthomas)
(In reply to Ben Hearsum [:bhearsum] from comment #14)
> RelEng certainly has places that we can generate and store the private key +
> resulting cert, but I think it would be much better for the folks that stage
> hotfixes to take on signing at this point. The only reason RelEng has been
> involved up until now is because the hotfix signing cert was the same
> certificate we use for Windows Authenticode signing, so it couldn't be
> shared outside of RelEng. Now that we're talking about a cert off the AMO
> root, keeping RelEng in the process is just adding unnecessary handoffs to
> the process.

That handoff is a kind of security barrier though. The AMO folks have their personal machines, or the process that's hooked up to the automated signing machines. If hotfix-signing is accessible through AMO itself then we're a website compromise away from a hotfix malware attack going to all Firefox users. In this case friction is good.
(In reply to Daniel Veditz [:dveditz] from comment #16)
> (In reply to Ben Hearsum [:bhearsum] from comment #14)
> > RelEng certainly has places that we can generate and store the private key +
> > resulting cert, but I think it would be much better for the folks that stage
> > hotfixes to take on signing at this point. The only reason RelEng has been
> > involved up until now is because the hotfix signing cert was the same
> > certificate we use for Windows Authenticode signing, so it couldn't be
> > shared outside of RelEng. Now that we're talking about a cert off the AMO
> > root, keeping RelEng in the process is just adding unnecessary handoffs to
> > the process.
> 
> That handoff is a kind of security barrier though. The AMO folks have their
> personal machines, or the process that's hooked up to the automated signing
> machines. If hotfix-signing is accessible through AMO itself then we're a
> website compromise away from a hotfix malware attack going to all Firefox
> users. In this case friction is good.

Makes sense. I'm still not sure why RelEng needs to be involved though. AMO folks could just as easily have a well protected machine to sign on, no?

I'm not pushing on this to try to get out of work, I just don't want hotfixes to be blocked unnecessarily for 8 hours (or an entire weekend) because RelEng isn't around to sign them.
Iteration: --- → 40.1 - 13 Apr
(In reply to Ben Hearsum [:bhearsum] from comment #17)
> Makes sense. I'm still not sure why RelEng needs to be involved though. AMO
> folks could just as easily have a well protected machine to sign on, no?
> 
> I'm not pushing on this to try to get out of work, I just don't want
> hotfixes to be blocked unnecessarily for 8 hours (or an entire weekend)
> because RelEng isn't around to sign them.

I think this is a good question to ask. Other than signing, releng isn't really involved in the hotfix process. We can certainly keep them involved for now but it may make sense to revisit releng involvement in this process.

(In reply to Dave Townsend [:mossop] from comment #13)
> Lawrence, just realised we don't have release management in here and as I
> noted in comment 10 the changes could cause us some extra work around
> releasing hotfixes during the transition. Do you have any concerns around
> that?

Like Dan (comment 16), I have a security concern about going with option #2.

I am somewhat concerned about the extra work for option #3. While we don't always release a hotfix for all Firefox versions, we do occasionally do this. The extra work in this case is really the overhead of following a different process when targeting Firefox versions pre add-on signing. However, I don't expect that this will be a big barrier and if this is the best option we should go with it.

As a question, in order to maintain a single add-on that can ship to all Firefox versions, is it possible to sign the hotfix with two keys and have Firefox accept one or the other?
Flags: needinfo?(lmandel)
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #18)
> (In reply to Ben Hearsum [:bhearsum] from comment #17)
> I am somewhat concerned about the extra work for option #3. While we don't
> always release a hotfix for all Firefox versions, we do occasionally do
> this. The extra work in this case is really the overhead of following a
> different process when targeting Firefox versions pre add-on signing.
> However, I don't expect that this will be a big barrier and if this is the
> best option we should go with it.

Just to be clear (assuming we turn on mandatory signing in Firefox 40) that extra work is only necessary if you want to release a hotfix that targets both Firefox <40 and Firefox >=40. If we don't care about release versions older than a few cycles then there are only a few cycles that this would be a burden.

> As a question, in order to maintain a single add-on that can ship to all
> Firefox versions, is it possible to sign the hotfix with two keys and have
> Firefox accept one or the other?

The JAR signing format allows for signing one add-on with multiple certificates but the code we have for verifying signatures in Firefox will only check one signature right now. That could be changed but for that to help this case we'd need to rollout that change to Firefox well in advance of the signing requirement change which would slow things down.
(In reply to Dave Townsend [:mossop] from comment #19)
> The JAR signing format allows for signing one add-on with multiple
> certificates but the code we have for verifying signatures in Firefox will
> only check one signature right now. That could be changed but for that to
> help this case we'd need to rollout that change to Firefox well in advance
> of the signing requirement change which would slow things down.

As it stands, does the verification code correctly verify one of the signatures? And, if so, is the process that chooses which one deterministic? If that's the case, we could probably add some sort of support for multiple signatures when signing rolls out, but still support older releases that only check one.

From our discussions on IRC, though, it seemed like this would much be more work than releasing multiple signed XPIs for several hotfixes. So, unless we're going to be releasing hotfixes that target very old Firefox versions, it doesn't seem like a very good option.

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #18)
> I think this is a good question to ask. Other than signing, releng isn't
> really involved in the hotfix process. We can certainly keep them involved
> for now but it may make sense to revisit releng involvement in this process.

I think it may be best if we leave responsibility for signing in the hands of releng for the initial roll-out, and then talk about adding a secure mechanism for signing hotfixes to the signing servers, or otherwise come up with another home for the key, once things settle down.
(In reply to Kris Maglione [:kmag] from comment #20)
> (In reply to Dave Townsend [:mossop] from comment #19)
> > The JAR signing format allows for signing one add-on with multiple
> > certificates but the code we have for verifying signatures in Firefox will
> > only check one signature right now. That could be changed but for that to
> > help this case we'd need to rollout that change to Firefox well in advance
> > of the signing requirement change which would slow things down.
> 
> As it stands, does the verification code correctly verify one of the
> signatures? And, if so, is the process that chooses which one deterministic?
> If that's the case, we could probably add some sort of support for multiple
> signatures when signing rolls out, but still support older releases that
> only check one.

I only skimmed over the code quickly but yes it looks like it may be deterministic and correctly ignore other certificates. Amusingly I may have spotted a bug in our current signature verification code at the same time.
Iteration: 40.1 - 13 Apr → 40.2 - 27 Apr
have we got a decision here folks? Mandatory signing is not a foregone conclusion here.
(In reply to Larissa Shapiro from comment #22)
> have we got a decision here folks? Mandatory signing is not a foregone
> conclusion here.

sorry. thats mandatory signing *in 40* is not a foregone conclusion, my read is that we're liking option #3 but concerned about the releng impact. Correct?
My only question on this is whether there is any reason we wouldn't give releng the signing key from AMO to sign hotfixes. Would releng infra support that and, if so, would it require any changes to process other than using a different key to sign the hotfix on generation?
Flags: needinfo?(bhearsum)
(In reply to Kev Needham [:kev] from comment #24)
> My only question on this is whether there is any reason we wouldn't give
> releng the signing key from AMO to sign hotfixes. Would releng infra support
> that and, if so, would it require any changes to process other than using a
> different key to sign the hotfix on generation?

We don't have "infra" that does addon signing. We simply have a copy of the cert/key and run commands by hand. The only reason we started doing it was because the old cert/key was the same as the one used for Authenticode signing.

In this new world where hotfixes have their own signing cert/key adding, I don't see any need for us to be involved. It seems like it would make more sense for someone who is already involved in the process to do the signing so we can avoid the unnecessary handoff to/from RelEng.
Flags: needinfo?(bhearsum)
So Option 3, then. I haven't seen any violent opposition, no calls pushing 1 or 2.

Make sense?
(and we'll also have to update hotfix release process and ensure releng and AMO are on the same page on how it'll work)
(In reply to Kev Needham [:kev] from comment #26)
> So Option 3, then. I haven't seen any violent opposition, no calls pushing 1
> or 2.
> 
> Make sense?

Makes sense. We need to generate a new signing certificate to use for this (filed bug 1155762). We also need to decide where this signing certificate is going to be kept.
AMO skipping the hotfix add-ons is bug 1155786
Whiteboard: [fxsearch][searchhijacking]
Priority: -- → P1
Iteration: 40.2 - 27 Apr → 40.3 - 11 May
In bug 1155762 we generated a new certificate for hotfix signing. How can we go about testing it? What is the current hotfix signing process?
(In reply to Jason Thomas [:jason] from comment #30)
> In bug 1155762 we generated a new certificate for hotfix signing. How can we
> go about testing it? What is the current hotfix signing process?

The current process is we upload an XPI to a bug and have releng sign it but we want to move that to somewhere else.

For now I'll be working on testing this tomorrow and will need an add-on signed by the hotfix cert so I can go make the relevant Firefox changes and verify them. I'll try to get that add-on uploaded somewhere by the end of today.
Flags: needinfo?(dtownsend)
The steps for publishing a hotfix are listed here: https://wiki.mozilla.org/Firefox/Hotfix

I think that the best way to test this, once the new code is ready in the client, is to re-sign the latest version of the hotfix using the new certificate, and publish it on stage. I'm not sure if we ever came to a decision on whether to try to sign the hotfixes with both the old an new key, though. That might complicate things slightly.
Dave, do you need to create a special add-on, or would a re-signed version of the latest hotfix work? Ideally I'd rather not have signed test versions of the hotfix in the wild, if we can avoid it.
(In reply to Kris Maglione [:kmag] from comment #33)
> Dave, do you need to create a special add-on, or would a re-signed version
> of the latest hotfix work? Ideally I'd rather not have signed test versions
> of the hotfix in the wild, if we can avoid it.

Yeah for now just a resigned version of an existing hotfix would be fine (one that installs on OSX would be good). I need to think more about what I'll need for an automated test, it's possible we might want a second dev cert for automated tests but we can cross that bridge if we come to it.
Flags: needinfo?(dtownsend)
I've created some test extensions in bug 1161311. They don't do anything other than setting prefs and aren't marked as compatible with Firefox so I don't think there is any issue with getting them signed and included in the source tree.
Depends on: 1161311
Attached patch patch (deleted) — — Splinter Review 
We don't expose the AMO chained certificates in a way that the current signing checks for the hotfix can get to so instead I've made the new signing checks do extra steps for the hotfix add-on by validating the signing cert against the fingerprints in prefs. This has the added benefit that where before we'd only check the hotfix add-on's certificate was correct when automatically installed we will now check it when manually installing and even detect if an installed hotfix is modified to something that is signed by AMO but not by the hotfix cert.

That might make testing hotfixes slightly harder but I chatted with felipe about this and he didn't think it would be much of a problem.

I've added the fingerprint for the new certificate to prefs so for now (as long as signing checks are disabled) either the new or old hotfix signing certificate can be used. Once signing checks are preffed on only the new hotfix cert will be usable.
Attachment #8602180 - Flags: review?(dveditz)
Comment on attachment 8602180 [details] [diff] [review]
patch

This looks good to me.

Leaving r?deveditz since he should also review this at some point.
Attachment #8602180 - Flags: review+
https://hg.mozilla.org/integration/fx-team/rev/b9276252c2e6
Backed out in https://hg.mozilla.org/integration/fx-team/rev/f5a38e9aaf68 for Windows debug failures in test_hotfix_cert.js, https://treeherder.mozilla.org/logviewer.html#?job_id=3017279&repo=fx-team
Mac debug, too.
Well, everywhere actually, stupid SETA just makes the results trickle in.
https://hg.mozilla.org/integration/fx-team/rev/2aa8aa1458b2
(In reply to Pulsebot from comment #42)
> https://hg.mozilla.org/integration/fx-team/rev/2aa8aa1458b2

Checked back in with a bustage fix to clear the cert fingerprint prefs first since the added prefs for the new cert were making the test behave incorrectly.
https://hg.mozilla.org/mozilla-central/rev/2aa8aa1458b2
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
QA Contact: vasilica.mihasca
Comment on attachment 8602180 [details] [diff] [review]
patch

Review of attachment 8602180 [details] [diff] [review]:
-----------------------------------------------------------------

r=dveditz
Attachment #8602180 - Flags: review?(dveditz) → review+
Is manual testing necessary for this issue?
Flags: needinfo?(dtownsend)
While this does have decent automated tests this is such a critical piece of our update system that we should do manual testing here.

What we need to do is create a simple test add-on, get it signed with the cert from bug 1155762. Felipe can help there, he has experience with the hotfix process.

Then follow the steps in https://developer.mozilla.org/en-US/Add-ons/Hotfix#Testing_the_hotfix_on_the_staging_server. Do this with xpinstall.signatures.required both true and false, the test hotfix should install in both cases.

The new hotfix cert will only work for Firefox 40 and 41, even if you mark the hotfix as compatible with Firefox 38 and 39 it shouldn't install there.
Flags: needinfo?(dtownsend) → needinfo?(felipc)
We need to test publishing separate hotfixes with the same code, but different signatures, one for 38/39, one for 40+, which means:

1) Create one hotfix with the `strictCompatibility` flag and support for Firefox 38-39.*, and a signature for that version.

2) Create one hotfix with or without the `strictCompatibility` flag, and support for Firefox 40-41.*, and a different version number (the same version number, but different suffixes, e.g., "-a" and "-b", would do).

3) Upload both versions to stage, and make both public.

4) Only after *both* versions have been made public, open Firefox 38 or 39, and make sure that correct hotfix is installed and works as expected.

5) Only after *both* versions have been made public, open Firefox 40 or 41, and make sure that correct hotfix is installed and works as expected.
Felipe can you work with Vasilica to create a test add-on for our QE team to use? Especially critical right now for 38 and 39 beta once this fix lands in beta. Thank you!
Florin, forgot to needinfo you yesterday as a heads up this may be coming to your team for testing. I think you already know about it --  just making sure.
Flags: needinfo?(vasilica.mihasca)
Flags: needinfo?(florin.mezei)
I encountered on addons-dev.allizom.org this hotfix add-on https://addons-dev.allizom.org/en-US/firefox/addon/firefox-hotfix/?src=ss but is not compatible with Firefox 38,39,40,41. Since Felipe didn’t answer to our requests I asked the web qa team to update it, in order to be compatible with the last 4 Firefox versions. 

They create me this add-on https://addons-dev.allizom.org/en-US/firefox/addon/firefox-hotfix-test-1/ . I installed it on latest Nightly (2015-06-11) and latest Aurora (2015-06-11) but it did not appear in about:addons.

Am I using a wrong add-on and this is why it does not appear in about:addons? or this is an issue?
Flags: needinfo?(vasilica.mihasca) → needinfo?(dtownsend)
(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #51)
> I encountered on addons-dev.allizom.org this hotfix add-on
> https://addons-dev.allizom.org/en-US/firefox/addon/firefox-hotfix/?src=ss
> but is not compatible with Firefox 38,39,40,41. Since Felipe didn’t answer
> to our requests I asked the web qa team to update it, in order to be
> compatible with the last 4 Firefox versions. 
> 
> They create me this add-on
> https://addons-dev.allizom.org/en-US/firefox/addon/firefox-hotfix-test-1/ .
> I installed it on latest Nightly (2015-06-11) and latest Aurora (2015-06-11)
> but it did not appear in about:addons.
> 
> Am I using a wrong add-on and this is why it does not appear in
> about:addons? 

Yeah, that hotfix doesn't have the correct versions. I'm finishing creating a set of xpis to test all the important cases as Kris mentioned in comment 48
Flags: needinfo?(felipc)
Flags: needinfo?(dtownsend)
Attached file test-hotfixes.zip (deleted) — 
So this contains 3 hotfixes:

- version=20150612.01 - strict compat, target versions 38.0-39.*,
- version=20150612.02 - strict compat, target versions 40.0-42.*
- version=20150612.03 - strict compat, target versions 40.0-42.*, with an incorrect id (firefox-hotfix-wrong@mozilla.org)


They contain some simple debugging to help testing:

on install, they will set the prefs to true:
 - hotfix.test.v3839  (or .v4042) to true
 - hotfix.test.willUninstall to true

After 1 minute, it will also set
 - hotfix.test.uninstalling to true,
 and should uninstall itself (and diseappear from about:addons after a refresh)


It will also set
 - hotfix.test.wrongVersion to true
 in case it gets incorrectly installed in the wrong version (which should not happen)
Jason, could you sign these 3 attached xpis, with the old (pre-40) and new signing certificates for hotfixes?
Flags: needinfo?(jthomas)
Attached file test-hotfixes-4042-signed.zip (deleted) — 
The attached zip includes hotfix-4042-correctid.xpi and hotfix-4042-wrongid.xpi signed with new signing certificate.

I don't have access to sign with the old certificate, who can do that?
Flags: needinfo?(jthomas)
(In reply to Jason Thomas [:jason] from comment #55)
> I don't have access to sign with the old certificate, who can do that?

Someone will need to file a bug in Release Engineering :: Releases
Filed (In reply to Kris Maglione [:kmag] from comment #56)
> Someone will need to file a bug in Release Engineering :: Releases

Filed bug 1174311 for that
I tested by drag & drop and these are the testing results:

[1] In Firefox 39 RC (20150622181234) and Firefox 38.0.6 (20150605094246)
    - hotfix3839-correctid-signed.xpi - installed, the prefs mentioned in Comment 53 were created and the add-on dissapeared  from Add-ons Manager after a minute  
    - hotfix-4042-correctid.xpi - not compatible with Firefox 39 (and Firefox 38.0.6)
    - hotfix-4042-wrongid.xpi - not compatible with Firefox 39 (and Firefox 38.0.6)

[2] In Firefox Firefox 40.0a2 (2015-06-22)
 *with xpinstall.signatures.required = true
    - hotfix3839-correctid-signed.xpi - not installed because appears to be corrupt
    - hotfix-4042-correctid.xpi - not compatible with Firefox 40.0a2
    - hotfix-4042-wrongid.xpi - not installed because appears to be corrupt

 *with xpinstall.signatures.required = false
    - hotfix3839-correctid-signed.xpi -  not compatible with Firefox 40.0a2
    - hotfix-4042-correctid.xpi - not compatible with Firefox 40.0a2
    - hotfix-4042-wrongid.xpi - not compatible with Firefox 40.0a2 

[3] In Firefox 41.0a1 (2015-06-22) 
 *with xpinstall.signatures.required = true
    - hotfix3839-correctid-signed.xpi - not installed because appears to be corrupt
    - hotfix-4042-correctid.xpi - installed, the prefs mentioned in Comment 53 were created and the add-on dissapeared from Add-ons Manager after a minute  
    - hotfix-4042-wrongid.xpi - not installed because appears to be corrupt

 *xpinstall.signatures.required = false
    - hotfix3839-correctid-signed.xpi -  not compatible with Firefox 41.0a1
    - hotfix-4042-correctid.xpi - installed, the prefs mentioned in Comment 53 were created and the add-on dissapeared from Add-ons Manager after a minute  
    - hotfix-4042-wrongid.xpi - installed, accompanied by a caution message, the prefs mentioned in Comment 53 were created and the add-on dissapeared from Add-ons Manager after a minute   

Tested under Windows 7-64bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5.

I think these add-ons need to be uploaded on stage, in order to be tested according to https://developer.mozilla.org/en-US/Add-ons/Hotfix#Testing_the_hotfix_on_the_staging_server
Can anyone please handle this?

The hotfix-4042-correctid.xpi and hotfix-4042-wrongid.xpi shouldn't be compatible with Firefox 40.0a2 ?
Flags: needinfo?(felipc)
(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #58)
> I tested by drag & drop and these are the testing results:
> 
> [1] In Firefox 39 RC (20150622181234) and Firefox 38.0.6 (20150605094246)
>     - hotfix3839-correctid-signed.xpi - installed, the prefs mentioned in
> Comment 53 were created and the add-on dissapeared  from Add-ons Manager
> after a minute  
>     - hotfix-4042-correctid.xpi - not compatible with Firefox 39 (and
> Firefox 38.0.6)
>     - hotfix-4042-wrongid.xpi - not compatible with Firefox 39 (and Firefox
> 38.0.6)
> 
> [2] In Firefox Firefox 40.0a2 (2015-06-22)
>  *with xpinstall.signatures.required = true
>     - hotfix3839-correctid-signed.xpi - not installed because appears to be
> corrupt
>     - hotfix-4042-correctid.xpi - not compatible with Firefox 40.0a2
>     - hotfix-4042-wrongid.xpi - not installed because appears to be corrupt
> 
>  *with xpinstall.signatures.required = false
>     - hotfix3839-correctid-signed.xpi -  not compatible with Firefox 40.0a2
>     - hotfix-4042-correctid.xpi - not compatible with Firefox 40.0a2
>     - hotfix-4042-wrongid.xpi - not compatible with Firefox 40.0a2 
> 
> [3] In Firefox 41.0a1 (2015-06-22) 
>  *with xpinstall.signatures.required = true
>     - hotfix3839-correctid-signed.xpi - not installed because appears to be
> corrupt
>     - hotfix-4042-correctid.xpi - installed, the prefs mentioned in Comment
> 53 were created and the add-on dissapeared from Add-ons Manager after a
> minute  
>     - hotfix-4042-wrongid.xpi - not installed because appears to be corrupt
> 
>  *xpinstall.signatures.required = false
>     - hotfix3839-correctid-signed.xpi -  not compatible with Firefox 41.0a1
>     - hotfix-4042-correctid.xpi - installed, the prefs mentioned in Comment
> 53 were created and the add-on dissapeared from Add-ons Manager after a
> minute  
>     - hotfix-4042-wrongid.xpi - installed, accompanied by a caution message,
> the prefs mentioned in Comment 53 were created and the add-on dissapeared
> from Add-ons Manager after a minute   
> 
> Tested under Windows 7-64bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5.
> 
> I think these add-ons need to be uploaded on stage, in order to be tested
> according to
> https://developer.mozilla.org/en-US/Add-ons/
> Hotfix#Testing_the_hotfix_on_the_staging_server
> Can anyone please handle this?
> 
> The hotfix-4042-correctid.xpi and hotfix-4042-wrongid.xpi shouldn't be
> compatible with Firefox 40.0a2 ?

They're explicitly marked compatible with 40.0 and higher, 40.0a2 is a lower version than 40.0 so I wouldn't expect them to install.

These results look like they match what I would expect, Felipe do they seem right to you?
Yeah, that look right. I am just wondering about the "appears to be corrupt" mention. I imagine it's just some confusing messaging because the add-on has the wrong certificate? Vasilica, could you take a screenshot of this error message?
Flags: needinfo?(felipc)
(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #58)
> I think these add-ons need to be uploaded on stage, in order to be tested
> according to
> https://developer.mozilla.org/en-US/Add-ons/
> Hotfix#Testing_the_hotfix_on_the_staging_server
> Can anyone please handle this?

Kris can handle the uploading the add-ons to staging.

Kris: can you upload both add-ons side-by-side to staging as we discussed? The 40-42 xpi is in this bug, and the 38-39 with the previous certificate is signed in bug 1174311
Flags: needinfo?(kmaglione+bmo)
(In reply to :Felipe Gomes from comment #60)
> Yeah, that look right. I am just wondering about the "appears to be corrupt"
> mention. I imagine it's just some confusing messaging because the add-on has
> the wrong certificate? Vasilica, could you take a screenshot of this error
> message?

Yes, when the add-on is signed but the certificate is incorrect in some way we just call it corrupt.
Both versions are currently live on AMO stage.

N.b., in the future please make sure that both the minVersion and maxVersion are listed on this page: https://addons.mozilla.org/pages/appversions/

When they're not, validation fails, so I need to override it and manually set the supported versions on AMO.
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(florin.mezei)
Verified fixed following the steps from https://developer.mozilla.org/en-US/Add-ons/Hotfix#Testing_the_hotfix_on_the_staging_server on Firefox 40 Beta 1 (20150702173756),Firefox 39 (20150630154324) and Firefox 38.0.6 (20150605094246) under Windows 7 64-bit, Windows 8.1 32-bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5.
Status: RESOLVED → VERIFIED
status-firefox39: --- → verified
status-firefox40: fixed → verified
So what is the new process for signing hotfixes ? Could someone update https://wiki.mozilla.org/Firefox/Hotfix with the answer ?
(In reply to Nick Thomas [:nthomas] from comment #65)
> So what is the new process for signing hotfixes ? Could someone update
> https://wiki.mozilla.org/Firefox/Hotfix with the answer ?

Jason, what is the best way to request a hotfix be signed with the certificate generated in bug 1155762? Just file a bug on Operations: Marketplace?
Flags: needinfo?(jthomas)
:kmag and :jorgev are the point of contact for signing a hotfix. They have been given instructions how to sign a hotfix using https://github.com/jasonthomas/sign-hotfix. I can sign them if they are not available.
Flags: needinfo?(jthomas) → needinfo?(kmaglione+bmo)
(In reply to Nick Thomas [:nthomas] from comment #65)
> So what is the new process for signing hotfixes ? Could someone update
> https://wiki.mozilla.org/Firefox/Hotfix with the answer ?

Ok I've updated that doc with what looks like the right way to do the signing step. I'm assuming the rest remains the same.
I'm not sure steps 3-6 need to be separate steps anymore, since the same people will generally be responsible for both parts. It should probably be: 3) Bug is assigned to the add-ons team for signing and staging. 4) Add-on is signed and staged...

Also, we should be using addons.allizom.org rather than addons-dev.allizom.org for staging.
Flags: needinfo?(kmaglione+bmo)
Adjusting this flag because it got me confused. It was verified that the intended behavior for 39 happened, which is: the hotfix didn't install because it was signed with the cert for 40. But it didn't mean that this bug was fixed for Firefox 39.
status-firefox39: verified → wontfix
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: