Opened 3 months ago

Last modified 9 days ago

#30957 needs_information enhancement

Allow '.asc' files to be downloaded using Tor browser (PGP ascii)

Reported by: torlove Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile
Cc: pili Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Using Tor browser for Android, one cannot download a '.asc' file by long-pressing it. The signature instead loads in a browser window. No helpful.

This might be the behaviour for Firefox but I expect better from Tor Browser frankly. In my experience copying ascii pgp from the browser introduces newline characters that break the signature.

Is there a temporary workaround for this in a config file? I would prefer the default behaviour for this text file to be "Save" but Save is not even an option.

Child Tickets

Change History (9)

comment:1 Changed 3 months ago by gk

Component: - Select a componentApplications/Tor Browser
Keywords: tbb-mobile added
Owner: set to tbb-team
Status: newneeds_information

I am not convinced we should change the default behavior for text files. Where did you copy the contents of the .asc file to? Does this happen if you copy the contents from a clean vanilla Fennec as well? Maybe that's a general bug Mozilla fixed meanwhile?

comment:2 Changed 3 months ago by torlove

Hello gk,

In my request I'm asking for the option to "Save" on long-press. It's relatively common today for people to long-press a link in order to download it.

The side request is asking whether there is a way to change the default behaviour for myself only, by editing a config file.

This problem of mismatching newline characters has happened to me. It is an arduous thing to fix on a small device, as one must manually remove the new lines and then re-input them in the text editor. Very error prone. Thankfully this did not happen on this occasion, however regardless of whether that happens or not, the user need to copy and paste the signature into a new text file, and then save that file to the correct folder, etc. Suboptimal.

Is there a security reason for ascii (incl. PGP signature) files to not be savable? By their very purpose they should be savable/downloadable by long-press. Any errors or problems in that process could easily be relayed to the user, hence aborting the download.

comment:3 Changed 3 months ago by torlove

Thanks for your prompt response, too, btw.

comment:4 in reply to:  2 Changed 3 months ago by gk

Replying to torlove:

Hello gk,

In my request I'm asking for the option to "Save" on long-press. It's relatively common today for people to long-press a link in order to download it.

Sounds reasonable to me. Again, what is Fennec doing here?

The side request is asking whether there is a way to change the default behaviour for myself only, by editing a config file.

Not sure.

This problem of mismatching newline characters has happened to me. It is an arduous thing to fix on a small device, as one must manually remove the new lines and then re-input them in the text editor. Very error prone. Thankfully this did not happen on this occasion, however regardless of whether that happens or not, the user need to copy and paste the signature into a new text file, and then save that file to the correct folder, etc. Suboptimal.

Agreed.

Is there a security reason for ascii (incl. PGP signature) files to not be savable? By their very purpose they should be savable/downloadable by long-press. Any errors or problems in that process could easily be relayed to the user, hence aborting the download.

No, there is no security reason for that AFAICT. And it might even be fixed in latest Fennec versions which would allow us to backport a patch maybe. So, again, could you try to figure out whether that experience is better for you?

comment:5 Changed 3 months ago by sysrqb

This is a bug in Fennec. Fennec does not provide an option for downloading/saving files. It only provides this for images. As far as I know, for every other html element type (simple links), it begins downloading the file and then the app 1) checks if it can handle the file itself (like text files), 2) checks if another app on the device can handle it (like pdfs), and 3) simply downloads the file.

I found these:
https://bugzilla.mozilla.org/show_bug.cgi?id=1546274

This isn't exactly the same bug, but it is similar. There are a few other bugs related to how Fennec handles downloads, too.

I suspect this will never be fixed in Fennec. Maybe Fenix will behave differently.

comment:6 Changed 2 months ago by torlove

Thanks for above responses. It's not good behaviour. It doesn't make sense and makes Fennec, and by extension Tor, less user friendly.

It looks like the may be garnering attention. In comment 9, literally a day after your response, sysrqb, Diana asks the person to create a new ticket for a .conf file:
https://bugzilla.mozilla.org/show_bug.cgi?id=1546274#c9

I have tried searching the bugtracker by the bug reporters name, "Dan Jacobson", but its not coming up with any results. Can someone please help confirm whether Dan has indeed opened a bug report for specifically downloading text files?

comment:7 Changed 7 weeks ago by pili

Cc: pili added

Even though one is to do with how the browser handles the files and the other one is about how we serve the files, I wonder if #31295 is related to this also...

comment:8 Changed 7 weeks ago by cypherpunks

this file is not safe, it is parsed by a software written in C and can cause RCE.

comment:9 Changed 9 days ago by torlove

Thanks cypherpunks,

At what point is it parsed, would it be parsed by the Firefox (and by extension the Tor Browser) and so therefore cause a vulnerability in the browser. Is there a method of parsing a '.asc' file without introducing a '.asc' vulnerabilty?

If this is an issue then it needs to be solved upstream as a matter of some urgency, yes?

Using a '.asc' file is supposed to be far more secure that a non ascii-armoured file, because the character space is far more limited, and thus we should be able to ensure that remote code cannot be delivered and excuted. I'm not an expert in this field and how to specifically deal with buffer overruns and such, but surely, any and all file type downloads need to account for this vulnerability, not just text files (or in this specific case, '.asc' files).

Note: See TracTickets for help on using tickets.