323826 - Uninstall of an extension that contains a windows .lnk fails (in some cases breaking all operations)

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Robert Strong (they/them - no direct email)]

Turns out that an extension was distributed that contains a xulrunner.lnk file that is zero bytes in size. I am sure that it was just an oversight by the extension author and this is an edgecase but it is an edgecase we should not fail on. Patch coming up.

Comment 1

[Robert Strong (they/them - no direct email)]

Attachment: patch (don't follow symbolic links)

Comment 2

[Robert Strong (they/them - no direct email)]

Comment on attachment 208795 [details] [diff] [review]
patch (don't follow symbolic links)

I'm going to look into this a little bit more... it turns out the install failed for me when the xpi contained a .lnk so I am not yet sure how this situation occured in the first place. The bug demonstrated by the files that were sent to me is fixed by the patch but it may need a bit more bullet proofing.

Comment 3

[Robert Strong (they/them - no direct email)]

Attachment: patch (never follow symbolic links returned from EM getDir functions)

Comment 4

[Robert Strong (they/them - no direct email)]

Fixed on trunk
new revision: 1.167; previous revision: 1.166

Comment 5

[Robert Strong (they/them - no direct email)]

Fixed on MOZILLA_1_8_BRANCH for Firefox 2.0

Comment 6

[Robert Strong (they/them - no direct email)]

*** Bug 318760 has been marked as a duplicate of this bug. ***

Comment 7

[Robert Strong (they/them - no direct email)]

Comment on attachment 208817 [details] [diff] [review]
patch (never follow symbolic links returned from EM getDir functions)

Requesting 1.8.0.2 - this is an edgecase but all we need to break the Extension Manager for a lot of users is for one popular extension to be distributed with a zero byte .lnk file in it. The only way for the user to recover is to manually delete the extension's directory when this occurs without this patch.

Comment 8

[Dave Liebreich [:davel]]

Comment on attachment 208817 [details] [diff] [review]
patch (never follow symbolic links returned from EM getDir functions)

as per discussion in triage meeting 23-feb-2006

Comment 9

[Darin Fisher]

Comment on attachment 208817 [details] [diff] [review]
patch (never follow symbolic links returned from EM getDir functions)

Hmm... setting followLinks to false has no effect on Linux.  Will this bug still occur on Linux with a malformed symlink?

Comment 10

[Robert Strong (they/them - no direct email)]

iirc this bug doesn't occur on Linux. I'll verify if / when I have the time if someone doesn't beat me to it.

Comment 11

[Daniel Veditz [:dveditz]]

Comment on attachment 208817 [details] [diff] [review]
patch (never follow symbolic links returned from EM getDir functions)

approved for 1.8.0 branch, a=dveditz for drivers

Comment 12

[Daniel Veditz [:dveditz]]

(In reply to comment #7)
> Requesting 1.8.0.2 - this is an edgecase but all we need to break the 
> Extension Manager for a lot of users

Could you elaborate? It sounds like you're saying it's worse than "can't uninstall this one extension". What does QA need to test?

Comment 13

[Robert Strong (they/them - no direct email)]

It can break extension installs, upgrades, and uninstalls for an extension. In thinking on it, I believe the original reporter had installed the extension with 1.0 which didn't have this problem and then upgraded. At that point there is no way to install, upgrade, or uninstall the extension except by manually removing it from the file system. Once this breakage occurs, the extension manager can end up in a state where additional operations will fail due to it trying to complete an operation - usually an uninstall - on the extension that contains a zero byte .lnk file.

I'll attach a testcase shortly

Comment 14

[Robert Strong (they/them - no direct email)]

Attachment: xpi testcase

A test xpi that contains a zero byte .lnk file which can't be uninstalled or upgraded with 1.5.0.x

Comment 15

[Robert Strong (they/them - no direct email)]

Checked in to MOZILLA_1_8_0_BRANCH

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.144.2.16.2.4; previous revision: 1.144.2.16.2.3