Sign and dev deploy the Firefox update hotfix (v20140527.01)

VERIFIED FIXED

Status

Release Engineering
Releases
P3
normal
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: gps, Assigned: spohl)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxgrowth])

Attachments

(17 obsolete attachments)

(Reporter)

Description

3 years ago
Created attachment 8483097 [details]
hotfix-v20140527.01.xpi

+++ This bug was initially created as a clone of Bug #1038561 +++

We're planning a minor v2 release of the Firefox update hotfix to address issues discovered with the first. Please sign the attached XPI and deploy to the *dev* server only.
Created attachment 8483699 [details]
signed hotfix

Here's the signed XPI. I'm not sure who deploys these, but it's not RelEng...
Jorge, are you still involved with staging hotfixes?
(Reporter)

Updated

3 years ago
Flags: needinfo?(jorge)
(In reply to Ben Hearsum [:bhearsum] from comment #2)
> Jorge, are you still involved with staging hotfixes?

Yup. The add-on is now available on staging.
Flags: needinfo?(jorge)
(Reporter)

Comment 4

3 years ago
Created attachment 8484233 [details]
hotfix-v20140527.01.xpi

We just had a last-minute addition to the hotfix over in bug 1062926. Please sign and deploy version 20140527.01.6.
(Reporter)

Updated

3 years ago
Attachment #8483097 - Attachment is obsolete: true
(Reporter)

Updated

3 years ago
Attachment #8483699 - Attachment is obsolete: true
Created attachment 8489791 [details]
hotfix-v20140527.01.signed.xpi

Here's the signed xpi, whether we want to use it now that we've shipped 32.0.1 is another question.
The signed XPI is now published on -dev.
I've been asked to see this bug through to completion.

My understanding is that I need to follow these steps:
  1) Verify that the signed XPI published on -dev is the same as the one attached to this bug
  2) Get QA sign-off (similar to bug 1038561 comment 6) on the published XPI
  3) File a bug similar to bug 1039605 to get this hotfix deployed in production


(In reply to Nick Thomas [:nthomas] from comment #5)
> Here's the signed xpi, whether we want to use it now that we've shipped
> 32.0.1 is another question.

I'm new to hotfixes, could you describe the issue here and what alternate steps I could take now that we've shipped 32.0.1?
Status: NEW → ASSIGNED
Flags: needinfo?(nthomas)
Summary: Sign and dev deploy the Firefox update hotfix (v20140527.01.5) → Sign and dev deploy the Firefox update hotfix (v20140527.01.6)
Assignee: nobody → tabraldes
We're shipping 32.0.3 and so we should update the hotfix to use the new installer. You should file a new bug for that: you can probably clone https://bugzilla.mozilla.org/show_bug.cgi?id=1052530 and follow the steps there: IIRC gps has a script which updates this and checks the signatures.
We will need QA signoff of the changes in v2, and specifically the one that needs manual verification is bug 1052519. See https://hg.mozilla.org/releases/firefox-hotfixes/ for the changelog.
Flags: needinfo?(nthomas)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> We're shipping 32.0.3 and so we should update the hotfix to use the new
> installer. You should file a new bug for that: you can probably clone
> https://bugzilla.mozilla.org/show_bug.cgi?id=1052530 and follow the steps
> there:

Filed bug 1072615 (Install Firefox 32.0.3 from hotfix) as a clone of bug 1061927 (Install Firefox 32 from hotfix).

> IIRC gps has a script which updates this and checks the signatures.

I was lead to believe that gps is unavailable on PTO; does anyone else know where that script lives?

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> We will need QA signoff of the changes in v2, and specifically the one that
> needs manual verification is bug 1052519. See
> https://hg.mozilla.org/releases/firefox-hotfixes/ for the changelog.

OK I'll request QA signoff after bug 1072615 is resolved and we've published the new XPI on -dev
Maybe https://hg.mozilla.org/releases/firefox-hotfixes/file/410e5fef2253/v20140527.01/import-installers.py.
Attachment #8484233 - Attachment is obsolete: true
Attachment #8489791 - Attachment is obsolete: true
Created attachment 8495485 [details]
Unsigned hotfix-v20140527.01.xpi

I created this by pulling the changes from bug 1072615 and then:
  HOTFIX=v20140527.01 make package

I think the next step is to sign and dev deploy
Flags: needinfo?(jorge)
Flags: needinfo?(bhearsum)
Created attachment 8496219 [details]
signed version of latest hotfix
Flags: needinfo?(bhearsum)
Deployed on dev.
Flags: needinfo?(jorge)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> We will need QA signoff of the changes in v2, and specifically the one that
> needs manual verification is bug 1052519. See
> https://hg.mozilla.org/releases/firefox-hotfixes/ for the changelog.

OK it's time for QA signoff.

:rail are you the right person for this?
:pauly I also needinfo'd you because you did the signoff in bug 1038561 comment 6

QA please verify what :bsmedberg mentioned in comment 9 and also that the hotfix correctly upgrades to 32.0.3
Flags: needinfo?(rail)
Flags: needinfo?(paul.silaghi)
(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #15)
> OK it's time for QA signoff.
> 
> :rail are you the right person for this?

Sorry, this is not me.

in bug 1028388 :pauly was involved. Maybe he knows...
Flags: needinfo?(rail)
I'll take care of this
QA Contact: rail → paul.silaghi
The hotfix doesn't seem to work on versions 10-17.
In browser console I see:
"Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://firefox-hotfix/update.jsm :: <TOP_LEVEL> :: line 1135"  data: no]
Source File: resource://firefox-hotfix/update.jsm
Line: 1135"

Works fine on FF 18-28.
Thoughts?
Flags: needinfo?(paul.silaghi) → needinfo?(tabraldes)
Created attachment 8496856 [details]
FF 10 browser console log.txt
To me that looks like a transient filesystem issue (Windows sometimes gets cranky when you try to delete files that you've recently been using), but if it happened consistently in FF10 through FF17 maybe there's more to it. Could you test once more on one of the versions that failed previously?

If it's not a transient issue, someone who understands the hotfix might be able to debug. :gps are you back from your long leave?
Flags: needinfo?(tabraldes)
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(gps)
Created attachment 8497359 [details]
FF 10 update log

(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #20)
> Could you test once more on one of the versions that failed previously?
I've tried on a different machine and the hotfix worked fine, although the above error still occurred.
I still reproduced the problem on the affected machine, same OS (Win 7 x64). The hotfix seems to be installed, the installer is downloaded, but the new version doesn't get installed. I'm attaching the update log, perhaps :gps finds something interesting in it.
Flags: needinfo?(paul.silaghi)
(Reporter)

Comment 22

3 years ago
(In reply to Paul Silaghi, QA [:pauly] from comment #18)
> The hotfix doesn't seem to work on versions 10-17.
> In browser console I see:
> "Error: [Exception... "Component returned failure code: 0x80004005
> (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005
> (NS_ERROR_FAILURE)"  location: "JS frame ::
> resource://firefox-hotfix/update.jsm :: <TOP_LEVEL> :: line 1135"  data: no]
> Source File: resource://firefox-hotfix/update.jsm
> Line: 1135"
> 
> Works fine on FF 18-28.
> Thoughts?

That could be a legitimate regression from bug 1052519, as line 1135 is calling Services.dirsvc.get("UpdRootD") and that appears to be throwing. Did UpdRootD not exist until Firefox 18? Let's investigate this in bug 1052519.
Flags: needinfo?(gps)
This sounds a bit similar to bug 1037649, the problem is the update isn't always done.
(In reply to Gregory Szorc [:gps] from comment #22)
> (In reply to Paul Silaghi, QA [:pauly] from comment #18)
> > The hotfix doesn't seem to work on versions 10-17.
> > In browser console I see:
> > "Error: [Exception... "Component returned failure code: 0x80004005
> > (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005
> > (NS_ERROR_FAILURE)"  location: "JS frame ::
> > resource://firefox-hotfix/update.jsm :: <TOP_LEVEL> :: line 1135"  data: no]
> > Source File: resource://firefox-hotfix/update.jsm
> > Line: 1135"
> > 
> > Works fine on FF 18-28.
> > Thoughts?
> 
> That could be a legitimate regression from bug 1052519, as line 1135 is
> calling Services.dirsvc.get("UpdRootD") and that appears to be throwing. Did
> UpdRootD not exist until Firefox 18? Let's investigate this in bug 1052519.

For clarity, did you mean that you will investigate the cause of this and update your patch? Or that I should take over in that bug? I assumed the former but perhaps that was wishful thinking ;)
Flags: needinfo?(gps)
(Reporter)

Comment 25

3 years ago
I thought the hotfix handoff was complete. I think someone who isn't me should look at this.

I'm still here to provide support as needed. Needinfo me if you get stuck.
Flags: needinfo?(gps)
OK I filed bug 1079439 as a follow-up to bug 1052519 and assigned it to myself. I'll see if I can fix the issue there and then report back on this bug when I've got a new XPI to sign, dev deploy, and QA
Created attachment 8509122 [details]
Unsigned hotfix-v20140527.01.xpi v2

Updated XPI with fix for bug 1079439. Please sign (:bhearsum) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release.

Thanks!
Attachment #8495485 - Attachment is obsolete: true
Attachment #8496219 - Attachment is obsolete: true
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bhearsum)
Pete is going to do the XPI signing a bit later.
Flags: needinfo?(bhearsum) → needinfo?(pmoore)
I've tried, but got stuck - I could not find the xpi signing key. I'm going to have to leave this for tonight as I have appointments, I can come back in the morning, but if someone else can help, that might be a better idea if this is urgent. Sorry!
Flags: needinfo?(pmoore)
Found the key on signing4 (wasn't on signing5) so I will proceed...
Created attachment 8510245 [details]
Signed hotfix-v20140527.01.xpi v2

Attachment 8509122 [details], signed with "Mozilla Corporation - DigiCert Inc" key.
Please note in the comment above, I referred to the unsigned attachment in the comment body - and I see now it could be easy to download the unsigned version, thinking it is the signed version. i.e.:

unsigned: attachment 8509122 [details]
signed:   attachment 8510245 [details]

Both are linked from comment 31 - so beware! :D
AMO doesn't handle repeated versions well, so I need the version number to be bumped up to 20140527.01.8 so I can stage it.
Flags: needinfo?(jorge)
(In reply to Jorge Villalobos [:jorgev] from comment #33)
> AMO doesn't handle repeated versions well, so I need the version number to
> be bumped up to 20140527.01.8 so I can stage it.

Gah, my bad! I haven't mastered the various details involved in releasing a hotfix. For whoever works on this next; the next step is to do a version bump like this:
  http://hg.mozilla.org/releases/firefox-hotfixes/rev/410e5fef2253
The following steps are:
  - Build the XPI
  - Attach the XPI here and request for it to be signed, dev-deployed, QA-signoff'ed
  - Once that is all done, request that the signed XPI be production-deployed

Reassigning to :rstrong so that this doesn't get lost as I transition out of Windows platform land.
Assignee: tabraldes → robert.strong.bugs
I'm happy to resign when it is ready. Are we still going ahead with this?

Thanks,
Pete
Meanwhile we keep building new releases the woes with graphics/OMTC, so lets make sure we're up to date with the current release when we do this again.

Comment 37

3 years ago
Is there are a target milestone for this V2 hotfix?
Hey folks. Just checking on the status here. The initial hotfix was a big success and we're just looking to close the loop.
(Assignee)

Comment 39

3 years ago
I'm slowly chipping away at this, but keep getting sidetracked by more urgent work. I'm still hoping to have a fresh hotfix (that updates to 33.1) ready for signing by end of week, or early next.
(Assignee)

Updated

3 years ago
Depends on: 1098559
Flags: needinfo?(paul.silaghi)

Comment 40

3 years ago
Given that Firefox 34 is right around the corner (11/25) would we *not* want to release this to close to release date? I assume it doesn't really matter since these are legacy users, but just thought about the scenario of a user upgrading and then a few days later 34 is released.

Updated

3 years ago
Whiteboard: [fxgrowth]
This shouldn't wait for any particular release. Let's just get it out the door.
(Assignee)

Comment 42

3 years ago
Created attachment 8524107 [details]
Unsigned hotfix-v20140527.01.xpi

I'm basically repeating comment 27 here, so hopefully the same people are still the right ones to ask for help here:

Please sign (:bhearsum) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release.

Thanks!
Assignee: robert.strong.bugs → spohl.mozilla.bugs
Attachment #8509122 - Attachment is obsolete: true
Attachment #8510245 - Attachment is obsolete: true
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bhearsum)
I should be able to do the signing tomorrow, in lieu of ben.
Flags: needinfo?(bhearsum) → needinfo?(bugspam.Callek)
Created attachment 8524705 [details]
Signed hotfix-v20140527.01.xpi

This is my first attempt at signing an xpi, so any/all verification that can be done would be appreciated.
Flags: needinfo?(bugspam.Callek)
The add-on is now approved on staging. Please verify it's working so we can push to production.
Flags: needinfo?(jorge)
(Assignee)

Comment 46

3 years ago
Paul, it'd be great if you could also verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail). Thanks!
(In reply to Jorge Villalobos [:jorgev] from comment #45)
> The add-on is now approved on staging. Please verify it's working so we can
> push to production.
Works fine on staging, old FF versions are updated to 33.1.1.
Tested on Win 7 on FF 10, 17, 24, 28 and Win XP on FF 13.0.1, 16.0.2, 17.0.1, 23, 27.0.1.
Note that the hotfix applies only to FF 10-28.

(In reply to Stephen Pohl [:spohl] from comment #46)
> Paul, it'd be great if you could also verify that the hotfix does not get
> applied if app.update.url.override is set to
> "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug
> 1098559 comment 10 for more detail). Thanks!
FF 10-16 still get updated with the pref set.
FF 17-28 don't get updated with the pref set.
I also notice that after the update was dropped due to the above pref, the hotfix still doesn't work if I remove the pref in about:config (using the same FF profile).
Flags: needinfo?(paul.silaghi)
(Assignee)

Comment 48

3 years ago
(In reply to Paul Silaghi, QA [:pauly] from comment #47)
> (In reply to Stephen Pohl [:spohl] from comment #46)
> > Paul, it'd be great if you could also verify that the hotfix does not get
> > applied if app.update.url.override is set to
> > "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug
> > 1098559 comment 10 for more detail). Thanks!
> FF 10-16 still get updated with the pref set.
> FF 17-28 don't get updated with the pref set.
> I also notice that after the update was dropped due to the above pref, the
> hotfix still doesn't work if I remove the pref in about:config (using the
> same FF profile).

Paul, you mentioned in bug 928173 comment 36 that the devices were being switched to the most recent version. In light of this, do you have any concerns about the hotfix still being applied to FF 10-16?
Flags: needinfo?(paul.cuthbert)

Comment 49

3 years ago
Yes we do. The issue is that there are still a large number of USB devices being used with FF 14.0.1. These are being replaced over time with new hardware and the latest FF version, and will be maintained via software update. However, the old devices are not remotely updated so will continue to be affected.
(Assignee)

Comment 50

3 years ago
I can't seem to apply the hotfix to a local Firefox 14.0.1 installation ("could not be installed because it is not compatible with Firefox 14.0.1"). :pauly, would you be able to either walk me through this or refer me to a document that explains how I can test this?
Flags: needinfo?(paul.silaghi)
(Assignee)

Comment 51

3 years ago
Robert, does bug 919033 comment 12 mean that we'll be applying a different hotfix to a 14.0.1 install first before installing the latest hotfix posted here? Do you think this might be the reason why Paul found that Firefox versions between 10-16 still get updated despite app.update.url.override being set?
Flags: needinfo?(robert.strong.bugs)
(In reply to Stephen Pohl [:spohl] from comment #50)
> :pauly, would you be able to either walk me through this or refer me to a
> document that explains how I can test this?
Steps:
1. Start FF with a new profile
2. Go to about:config and set:
   - extensions.logging.enabled=TRUE
   - in the pref "extensions.update.background.url" (extensions.update.url for Firefox < 13), change the "versioncheck-bg.addons.mozilla.org" part from the string with "addons-dev.allizom.org"
3. Restart FF
4. Open Addons Manager
5. Open the Browser Console and clear it so you can see the update requests
6. Open Scratchpad and run (3 times for FF 10-16) the following code snippet:
var obj = {};
Cu.import("resource://gre/modules/AddonManager.jsm", obj);
obj.AddonManagerPrivate.backgroundUpdateCheck();
7. Wait a bit until the update is applied, then restart FF
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(paul.cuthbert)
(In reply to Stephen Pohl [:spohl] from comment #51)
> Robert, does bug 919033 comment 12 mean that we'll be applying a different
> hotfix to a 14.0.1 install first before installing the latest hotfix posted
> here?
3 hotfixes are used for FF 10-16.0.1:
hotfix version 20121019.01
hotfix version 20130826.01
hotfix version 20140527.01.8

Starting with FF 16.0.2, only the last 2 are used.
But I don't understand why FF 16.0.2 is still updated with the app.update.url.override set and FF 17 is not.
(In reply to Stephen Pohl [:spohl] from comment #51)
> Robert, does bug 919033 comment 12 mean that we'll be applying a different
> hotfix to a 14.0.1 install first before installing the latest hotfix posted
> here?
I think it means that profiles that have applied the fingerprint hotfix will be able to apply a later hotfix.

> Do you think this might be the reason why Paul found that Firefox
> versions between 10-16 still get updated despite app.update.url.override
> being set?
I don't see how though possibly.
Flags: needinfo?(robert.strong.bugs)
(Assignee)

Comment 55

3 years ago
(In reply to Paul Silaghi, QA [:pauly] from comment #52)
> (In reply to Stephen Pohl [:spohl] from comment #50)
> > :pauly, would you be able to either walk me through this or refer me to a
> > document that explains how I can test this?
> Steps:
> 1. Start FF with a new profile
> 2. Go to about:config and set:
>    - extensions.logging.enabled=TRUE
>    - in the pref "extensions.update.background.url" (extensions.update.url
> for Firefox < 13), change the "versioncheck-bg.addons.mozilla.org" part from
> the string with "addons-dev.allizom.org"
> 3. Restart FF
> 4. Open Addons Manager
> 5. Open the Browser Console and clear it so you can see the update requests
> 6. Open Scratchpad and run (3 times for FF 10-16) the following code snippet:
> var obj = {};
> Cu.import("resource://gre/modules/AddonManager.jsm", obj);
> obj.AddonManagerPrivate.backgroundUpdateCheck();
> 7. Wait a bit until the update is applied, then restart FF

When I run this with Firefox 14.0.1 and I have no app.update.url.override set, a restart still shows 14.0.1, but opening the Firefox About dialog starts downloading 33.1.1. Clicking the "Restart" button will apply 33.1.1 and restart Firefox.

If I have app.update.url.override set to "https://update.commbiz.commbank.com.au", all the hotfixes get downloaded and installed (according to the Error Console). However, when I restart Firefox and launch the About dialog, I'm told that 14.0.1 is up to date.

Paul, it seems like I'm still missing a step to reproduce what you're seeing...
Flags: needinfo?(paul.silaghi)
(In reply to Stephen Pohl [:spohl] from comment #55)
> When I run this with Firefox 14.0.1 and I have no app.update.url.override
> set, a restart still shows 14.0.1, but opening the Firefox About dialog
> starts downloading 33.1.1. Clicking the "Restart" button will apply 33.1.1
> and restart Firefox.
If you're opening the Help/About dialog then the hotfix will have no job anymore, cause FF will upgrade anyway.
In the step 7 comment 52, FF 33.1.1 should be downloaded and installed automatically in the background (no Help/About needed). Just wait ~1 min (may take longer on slow internet connections) and then restart. After this you should see the new version. Type about: in the location bar to check the version.
Just checked on FF 14.0.1 and the update is still applied with app.update.url.override set.
Flags: needinfo?(paul.silaghi)
Here is a screencast showing the problem: http://screencast.com/t/RFnuywr4
(Assignee)

Comment 58

3 years ago
(In reply to Paul Silaghi, QA [:pauly] from comment #57)
> Here is a screencast showing the problem: http://screencast.com/t/RFnuywr4

Thank you! I'm now able to reproduce the problem. Unfortunately, I have no idea why this isn't working yet. If somebody happens to know where the log calls from update.jsm are going, or how I can enable it, please let me know.
(Assignee)

Comment 59

2 years ago
Once I found where the logs were written to (hotfix-update directory in user profile, but directory will get deleted if browser is restarted after update), this turned out to be a pretty silly problem. A new patch is awaiting review in bug 1098559 and I'll be posting a new hotfix for signing and QA signoff here once the patch has been reviewed and landed.
(Assignee)

Updated

2 years ago
Attachment #8524107 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8524705 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8497359 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8496856 - Attachment is obsolete: true
(Assignee)

Comment 60

2 years ago
Created attachment 8528505 [details]
Unsigned hotfix-v20140527.01.xpi

Ok, let's try this again.

Please sign (:Callek) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release. In particular:
1. Please verify comment 9.
2. Please verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail). Thanks!

Thanks!
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bugspam.Callek)
(Assignee)

Comment 61

2 years ago
Comment on attachment 8528505 [details]
Unsigned hotfix-v20140527.01.xpi

Hmm, comment 33 makes me think that I need to bump the version number. :jorgev, let me know if that's not the case.
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(bugspam.Callek)
(Assignee)

Comment 62

2 years ago
Created attachment 8528511 [details]
Unsigned hotfix-v20140527.01.xpi

Bumped version number to 20140527.01.9.

Please sign (:Callek) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release. In particular:
1. Please verify comment 9.
2. Please verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail). Thanks!

Thanks!
Attachment #8528505 - Attachment is obsolete: true
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(bugspam.Callek)
Created attachment 8528514 [details]
hotfix-v20140527.01-signed.xpi
Flags: needinfo?(bugspam.Callek)
(In reply to Stephen Pohl [:spohl] from comment #61)
> Hmm, comment 33 makes me think that I need to bump the version number.
> :jorgev, let me know if that's not the case.

Yes, a version bump is necessary if the previous version was uploaded to stage or prod.

The new version is now available on staging.
Flags: needinfo?(jorge)
The hotfix is not working at all, tested on FF 10, 28.
Browser console log:
"A required certificate was not present. CertUtils.jsm:77
WARN addons.manager: The hotfix add-on was not signed by the expected certificate and so will not be installed. AddonManager.jsm:1100
LOG addons.xpi: Cancelling download of https://addons-dev-cdn.allizom.org/user-media/addons/354399/mozilla_firefox_hotfix-20140527.01.9-fx.xpi"
Flags: needinfo?(paul.silaghi)
(Assignee)

Comment 66

2 years ago
:jorgev, based on the checksums it looks like the unsigned hotfix was uploaded to staging. Can it be replaced by the signed one, or do we need another version bump?
Flags: needinfo?(jorge)
(In reply to Stephen Pohl [:spohl] from comment #66)
> :jorgev, based on the checksums it looks like the unsigned hotfix was
> uploaded to staging. Can it be replaced by the signed one, or do we need
> another version bump?

Ugh, sorry about that. Yes, we'll need another version bump :(
Flags: needinfo?(jorge)
(Assignee)

Updated

2 years ago
Summary: Sign and dev deploy the Firefox update hotfix (v20140527.01.6) → Sign and dev deploy the Firefox update hotfix (v20140527.01)
(Assignee)

Updated

2 years ago
Attachment #8528514 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8528511 - Attachment is obsolete: true
(Assignee)

Comment 68

2 years ago
Created attachment 8529837 [details]
Unsigned hotfix-v20140527.01.xpi

Bumped version number to 20140527.01.10.

Please sign (:Callek) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release. In particular:
1. Please verify comment 9.
2. Please verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail).

Thanks!
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bugspam.Callek)
I'm based out of the usa. Punting to ben.
Flags: needinfo?(bugspam.Callek) → needinfo?(bhearsum)
What's the urgency on this?
Flags: needinfo?(bhearsum) → needinfo?(spohl.mozilla.bugs)
(Assignee)

Comment 71

2 years ago
It seems like this should ship before we release FF34, or we'll have to do this over (again) and change the hotfix to update to FF34 instead of FF33.1.1. Also note comment 41.
Flags: needinfo?(spohl.mozilla.bugs)
(In reply to Stephen Pohl [:spohl] from comment #71)
> It seems like this should ship before we release FF34, or we'll have to do
> this over (again) and change the hotfix to update to FF34 instead of
> FF33.1.1. Also note comment 41.

Aren't we going to have to do that anyways after Fx34 ships?
(Assignee)

Comment 73

2 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #72)
> (In reply to Stephen Pohl [:spohl] from comment #71)
> > It seems like this should ship before we release FF34, or we'll have to do
> > this over (again) and change the hotfix to update to FF34 instead of
> > FF33.1.1. Also note comment 41.
> 
> Aren't we going to have to do that anyways after Fx34 ships?

As long as we get the hotfix out the door before FF34 ships we should be good to go. If we decide to ship another hotfix, it will update to whatever is the current version at that time.
(Assignee)

Comment 74

2 years ago
Arguably, the FF34 release on 12/1 is coming up very shortly (I thought it was later). Benjamin, do you think we should hold off on releasing the hotfix for 33.1.1 and change it to update to FF34 instead?
Flags: needinfo?(benjamin)
(In reply to Stephen Pohl [:spohl] from comment #73)
> (In reply to Ben Hearsum [:bhearsum] from comment #72)
> > (In reply to Stephen Pohl [:spohl] from comment #71)
> > > It seems like this should ship before we release FF34, or we'll have to do
> > > this over (again) and change the hotfix to update to FF34 instead of
> > > FF33.1.1. Also note comment 41.
> > 
> > Aren't we going to have to do that anyways after Fx34 ships?
> 
> As long as we get the hotfix out the door before FF34 ships we should be
> good to go. If we decide to ship another hotfix, it will update to whatever
> is the current version at that time.

Right...but if everyone updates to 34 this next, many people wouldn't have had time to get this hotfix, right?
Don't wait.
Flags: needinfo?(benjamin)
(Assignee)

Comment 77

2 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #75)
> (In reply to Stephen Pohl [:spohl] from comment #73)
> > (In reply to Ben Hearsum [:bhearsum] from comment #72)
> > > (In reply to Stephen Pohl [:spohl] from comment #71)
> > > > It seems like this should ship before we release FF34, or we'll have to do
> > > > this over (again) and change the hotfix to update to FF34 instead of
> > > > FF33.1.1. Also note comment 41.
> > > 
> > > Aren't we going to have to do that anyways after Fx34 ships?
> > 
> > As long as we get the hotfix out the door before FF34 ships we should be
> > good to go. If we decide to ship another hotfix, it will update to whatever
> > is the current version at that time.
> 
> Right...but if everyone updates to 34 this next, many people wouldn't have
> had time to get this hotfix, right?

The hotfix is for people who are stuck on old versions, so will still be relevant. Per comment 76, let's get this signed and out the door.
Created attachment 8529971 [details]
hotfix-v20140527.01-signed.xpi
The signed version is now staged. Please test.
Flags: needinfo?(jorge)
Works fine on staging.
Tested on FF 10, 14.0.1, 16.0.1, 17, 20, 24, 28 both with/without the "app.update.url.override" pref.
Flags: needinfo?(paul.silaghi)
(Assignee)

Comment 81

2 years ago
:jorgev, is it you who typically pushes this live? Anything else we need to do before releasing?
Flags: needinfo?(jorge)
(In reply to Stephen Pohl [:spohl] from comment #81)
> :jorgev, is it you who typically pushes this live? Anything else we need to
> do before releasing?

Yes, it's just a matter of pushing it live. Are we good to go?
Flags: needinfo?(jorge)
Yes and thanks!
Flags: needinfo?(jorge)
The signed add-on is now available on AMO.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(jorge)
Resolution: --- → FIXED

Comment 85

2 years ago
This hot fix directly links to ftp.m.o rather than bouncer. It is hard coded. 
from whine @3:10p pst that this hot fix has been pulled.

Updated

2 years ago
See Also: → bug 1107156
(Assignee)

Updated

2 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Updated

2 years ago
Blocks: 1107156
(Assignee)

Updated

2 years ago
Attachment #8529971 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8529837 - Attachment is obsolete: true
The new version is now available on AMO.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
(In reply to Jorge Villalobos [:jorgev] from comment #86)
> The new version is now available on AMO.

gps created a new xpi and I signed it (over in Bug 1107156)
(In reply to Paul Silaghi, QA [:pauly] from comment #80)
> Works fine on staging.
> Tested on FF 10, 14.0.1, 16.0.1, 17, 20, 24, 28 both with/without the
> "app.update.url.override" pref.
Works fine in production too.
Status: RESOLVED → VERIFIED
(Assignee)

Updated

2 years ago
Blocks: 1110340
You need to log in before you can comment on or make changes to this bug.