1755566 - Manually canceling download after marking part file read-only should not reuse part file name when retried

Status: NEW

(Toolkit :: Downloads API, defect, P5)

Description

[Adrian Florinescu [:aflorinescu]]

Note

• IMO, in the case in which the download is canceled, retrying the download should basically be considered the same use-case as a new download from the part randomizer point of view and a new random string should be generated.
  * copying download link and starting a secondary clone download will use the same random string as the first download

Affected versions

• Firefox 98 beta 4
• Nightly 99.0a1

Affected platforms

• all

Steps to reproduce

1. Download a big file e.g.: download ubuntu
2. While downloading, right click on the ongoing download and “Show in folder/finder”
3. While downloading, edit the .part permissions making it a readonly.
4. Cancel the download.
5. Retry the download and wait for completion.

Expected result

• The download is completed. (without the improvements enabled / without having +random.part the download will still fail)

Actual result

• Download failed due to trying to reuse the .part used at step 3

Regression range

• Not a regression

Comment 1

[Armin Ebert [:arminius]]

(I'm not involved in this feature, so just ignore this comment if it isn't relevant.)

(In reply to Adrian Florinescu [:aflorinescu] from comment #0)

• copying download link and starting a secondary clone download will use the same random string as the first download

If the download link is copied and opened again manually, it actually does use a new random name on my end.

4. Cancel the download.
5. Retry the download and wait for completion.

If the download is retried by clicking the retry button in the downloads popup, I can reproduce the behavior as described.

I agree that there may be sec implications if a random name is reused when retrying a cancelled download. However, in the case that a half-completed download is interrupted due to browser exit/crash, the browser would also, upon restart, have to be able to resume download from the already received .part. So, resuming an interrupted download may be a use case where one might still want to use the old random.

Comment 2

[Adrian Florinescu [:aflorinescu]]

(In reply to Armin Ebert [:arminius] from comment #1)

(I'm not involved in this feature, so just ignore this comment if it isn't relevant.)

(In reply to Adrian Florinescu [:aflorinescu] from comment #0)

• copying download link and starting a secondary clone download will use the same random string as the first download

If the download link is copied and opened again manually, it actually does use a new random name on my end.

Correct, might be a weird usecase in which this happens. I've updated the summary until I'm going to figure out if there's another issue in which the random part is reused.

4. Cancel the download.
5. Retry the download and wait for completion.

If the download is retried by clicking the retry button in the downloads popup, I can reproduce the behavior as described.

I agree that there may be sec implications if a random name is reused when retrying a cancelled download. However, in the case that a half-completed download is interrupted due to browser exit/crash, the browser would also, upon restart, have to be able to resume download from the already received .part. So, resuming an interrupted download may be a use case where one might still want to use the old random.

I don't think pause/resume or crash/resume would enter under the circumstance of new part file. I was not implying that pause/resume should reroll the randomizer, just when new part file is generated, we should use new randomizer.

Comment 3

[:Gijs (he/him)]

Does the same issue happen if you skip step (3), ie if you just cancel the download without changing the file's permissions?

Comment 4

[Adrian Florinescu [:aflorinescu]]

(In reply to :Gijs (he/him) from comment #3)

Does the same issue happen if you skip step (3), ie if you just cancel the download without changing the file's permissions?

No.

Comment 5

[Adrian Florinescu [:aflorinescu]]

Firefox 98 shipping soon, hence updating flags to reflect the status quo.

Comment 6

[:Gijs (he/him)]

I think given the requirement to mark read-only first (which an attacker is unlikely to be able to do if they don't already have significantly more privileges), this doesn't need to be high-priority.