Closed Bug 1231849 Opened 4 years ago Closed 2 years ago

Firefox only detects changes to disabled add-ons if their install.rdf mtime is newer than the mtime of any file/directory in the old files

Categories

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

42 Branch
defect

Tracking

()

RESOLVED INACTIVE
Tracking Status
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected
firefox46 --- affected
firefox-esr38 --- affected

People

(Reporter: adolf_daniel, Unassigned)

References

Details

(Whiteboard: triaged)

Attachments

(2 files)

788.55 KB, application/x-7z-compressed
Details
1.71 MB, application/octet-stream
Details
Attached file side_loading_issue.7z
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.22 Safari/537.36

Steps to reproduce:

1. Extract an unsigned extension and side load the extension
 1.1. Extract the files from Firefox_unsigned_86.zip to c:\Firefox
 1.2. Run the attached FFSideLoading.reg to add the side loading registries
2. Open Firefox 42/43Beta and enable the extension
3. Disable the extension after the extension get enabled
4. Close Firefox
5. Extract the signed extension (Firefox_signed_86.zip) and replace the files in the side loaded directory (c:\Firefox)
6. Open Firefox and check the addons page


Actual results:

The extension should be shown as signed


Expected results:

The extension is still shown as not signed
Comment on attachment 8697439 [details]
side_loading_issue.7z

This attachment contains the following.
1. Signed extension archive
2. Unsigned extension archive
3. Registry file for side loading the extensions.
Priority: -- → P2
This issue does not occur if the extension is not disabled as mentioned in step 3.
Component: Untriaged → Extension Compatibility
Component: Extension Compatibility → Add-ons Manager
Product: Firefox → Toolkit
The files in both signed and unsigned XPIs all have identical file modification times. Firefox uses the file modification time to detect whether an extension has changed on startup so if your method for extracting the XPI preserves those modification times (regular unzip does, probably most zip tools do) then Firefox won't see the extension as changed and so won't re-check the signatures.

I would expect the problem to go away if after extracting you updated the modification time of install.rdf to something newer.
Thank you Dave for the reply.

This issue happens even if I use different time stamps (even different versions). I tried using a completely different version (lower version) of unsigned extension and upgraded to a newer signed extension. I could still see the issue. As per my previous comment, this issue happens only of the extension is disabled during upgrade. The issue does not appear if the extension is already enabled.
Can you attach the examples you're talking about there? When disabled I think we only check the modification time of install.rdf so that definitely must differ.
I have attached the older version file Firefox_unsigned_78.zip (2015.5.6.78).

Steps to reproduce:

1. Extract an unsigned extension and side load the extension
 1.1. Extract the files from Firefox_unsigned_78.zip (inside side_loading_issue.7z) to c:\Firefox
 1.2. Run the attached FFSideLoading.reg (inside side_loading_issue.7z) to add the side loading registries
2. Open Firefox 42/43Beta and enable the extension
3. Disable the extension after the extension get enabled
4. Close Firefox
5. Extract the signed extension (Firefox_signed_86.zip) and replace the files in the side loaded directory (c:\Firefox)
6. Open Firefox and check the addons page


Actual results:
The extension should be shown as signed and show the new version (86)


Expected results:
The extension is still shown as not signed and shows the older version (78).

You can see that the timestamp of both these versions are completely different.

I observed that the new extension files (javascript files) are loaded by Firefox when I enable the extension after the upgrade. But still the version and signing of the extension is not updated in the addon page.

Also, if I open the install.rdf file after upgrade in notepad.exe, save and close the file, the Firefox is picking up the signing properly. But, if I change the modified timestamp of the install.rdf file to current time using ::SetFileTime() api then Firefox is not picking up the change.

Please let me know if I'm missing something about changing the timestamp.
We have received a couple additional reports of the same or similar problems, in the forum [1] and by email.

[1] https://discourse.mozilla-community.org/t/firefox-fails-to-detect-updates-for-unpacked-extension-installed-through-windows-registry
We are also getting the same issue. Below are our steps to reproduce
1.Extract unsigned extension folder
2.Add registry entries
3.Launch Firefox, extension remains disabled with warning
4.Delete unsigned extension folder and replace with Extracted signed addon folder
5.Launch firefox
6.Under Addons, extension is disabled and shows warning.
  Please note, still it is pointing to old copy of unsigned Addon version

We observed that under settings "extensions.xpiState" it is still pointing to old unsigned extension.

One way to have it working is
1.After deleting old copy of unsigned extension folder
2.Launch firefox and close it[This is required]
3.Now copy signed extension folder
4.Launch firefox, you would be getting signed version of addon without warnings.
Assignee: nobody → dtownsend
I've managed to reproduce what I think is going on here and it ties to a complication in how we decide if a disabled extension has changed. The upshot is that until we can figure out a fix in Firefox you should be able to work around the problem by setting the modification time of install.rdf to the current time when installing your sideloaded extension. I've updated the docs at https://developer.mozilla.org/en-US/docs/Adding_Extensions_using_the_Windows_Registry to mention that.

I've verified with the attached examples that after updating the extension's files with the signed zip copies and then running "touch install.rdf" Firefox picks up the changes. Without that touch call it does not.

When an extension is installed and for as long as it is enabled on every startup we scan the directory and all files in it. The last update time of the extension is set by the most recently changed file/directory in the entire extension. This includes the modification time of the extension directory itself. If the installing program is manually creating this directory then that will often be newer than any of the files in a zip file that is extracted there.

When an extension is disabled we stop doing full scans and instead only look at the modification time of install.rdf. The problem is that if the modification time of install.rdf is older than the last update time of the extension as of the last full scan (the last time the extension was enabled) then we assume the extension hasn't changed.

So if you extract a zip and the install.rdf in there has a modification time older than the time the extension's directory was created and the extension is already disabled for some reason then Firefox won't detect the change and won't reload install.rdf and do the signing checks.
Summary: Extension update fails for disabled side loaded extension (affecting signed extension release) → Firefox only detects changes to disabled add-ons if their install.rdf mtime is newer than the mtime of any file/directory in the old files
(In reply to Adolf Daniel from comment #6)
> 5. Extract the signed extension (Firefox_signed_86.zip) and replace the
> files in the side loaded directory (c:\Firefox)

Please make sure that when you do this you remove any files from the directory not present in the new extension version. When I tested with the attached 78 zip file and updated to the signed 86 version at first I saw signing errors because the old version has some files that the new version does not. Any additional files present will cause signing to fail.
Our observation: After touching the install.rdf, the add-on signing is recognized. But the add-on is disabled and user needs to manually enable it. 

Any thoughts to avoid user intervention?
(In reply to ajithtpillai from comment #11)
> Our observation: After touching the install.rdf, the add-on signing is
> recognized. But the add-on is disabled and user needs to manually enable it. 
> 
> Any thoughts to avoid user intervention?

This will happen if the first time that user's profile saw the add-on it was unsigned, in that case we don't offer to enable the sideloaded add-on because it can't be enabled and then the later change is just an update. I don't think there is an easy way around that right now. You would need to remove the add-on let the user start Firefox to see it is gone and then sideload it again.
This is a major flaw in the feature that was put into FF 43 where this major capability for add-ons was not tested.  Anything to fix this now requires a user-intervention once they have upgraded to 43 and got themselves in the bad state.  This is unfortunately a major issue for large organizations as they cannot ask each user to go to the tools->add-ons and enable the plug-in once a signed copy is deployed and install.rdf is touched.  Is there an automated way to enable the plug-in?  If not, Mozilla should really re-think if this should be pulled until it's tested and all the use-cases are covered.
(In reply to Raj Patil from comment #13)
> This is a major flaw in the feature that was put into FF 43 where this major
> capability for add-ons was not tested.  Anything to fix this now requires a
> user-intervention once they have upgraded to 43 and got themselves in the
> bad state.

This bug has actually been present since Firefox 35, we're just only seeing it be more prevalent now because it is biting developers who didn't update their add-ons in time for Firefox 43's release.

> This is unfortunately a major issue for large organizations as
> they cannot ask each user to go to the tools->add-ons and enable the plug-in
> once a signed copy is deployed and install.rdf is touched.  Is there an
> automated way to enable the plug-in?  If not, Mozilla should really re-think
> if this should be pulled until it's tested and all the use-cases are covered.

The only way I can think of is to change the ID of your add-on. This would cause Firefox to see it as an entirely new add-on and so present the sideloading UI to the user again.
(In reply to Dave Townsend [:mossop] from comment #12)
> (In reply to ajithtpillai from comment #11)
> > Our observation: After touching the install.rdf, the add-on signing is
> > recognized. But the add-on is disabled and user needs to manually enable it. 
> > 
> > Any thoughts to avoid user intervention?
> 
> This will happen if the first time that user's profile saw the add-on it was
> unsigned, in that case we don't offer to enable the sideloaded add-on
> because it can't be enabled and then the later change is just an update. I
> don't think there is an easy way around that right now. You would need to
> remove the add-on let the user start Firefox to see it is gone and then
> sideload it again.

I've split this issue off into bug 1237820 to try to figure out a fix there. The remaining issue in this bug related to file modification times can be worked around relatively easily so will be a lower priority right now.
Can this bug transition to "new" status now?
(In reply to Matt Powers from comment #16)
> Can this bug transition to "new" status now?

Sure, it doesn't have much meaning though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 1240191
Duplicate of this bug: 1246097
@Dave which version is this planned to be fixed? Will it be done before Firefox 46 release where xpinstall preference is to be disabled? Also from https://wiki.mozilla.org/Addons/Extension_Signing#Timeline, would the preference also be disabled in 45.1 ESR parallel to 46 Release version? Thanks.
Flags: needinfo?(dtownsend)
(In reply to ajithtpillai from comment #19)
> @Dave which version is this planned to be fixed? Will it be done before
> Firefox 46 release where xpinstall preference is to be disabled? Also from
> https://wiki.mozilla.org/Addons/Extension_Signing#Timeline, would the
> preference also be disabled in 45.1 ESR parallel to 46 Release version?
> Thanks.

No-one is actively working on this right now so no it won't be fixed for Firefox 46. I can't say if 45 ESR has signing force on but I doubt it.
Flags: needinfo?(dtownsend) → needinfo?(kev)
Whiteboard: triaged
Assignee: dtownsend → nobody
(In reply to Dave Townsend [:mossop] from comment #20)
> 
> No-one is actively working on this right now so no it won't be fixed for
> Firefox 46. I can't say if 45 ESR has signing force on but I doubt it.

Apologies, missed this. ESR has signing enabled by default. but will maintain the pref to disable it. There are no plans to remove the pref from ESR releases at this time.
Flags: needinfo?(kev)
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.