Closed Bug 1574475 (kill-ftp) Opened 2 years ago Closed 3 months ago

Remove FTP support

Categories

(Core :: Networking: FTP, task, P2)

task

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox90 --- fixed

People

(Reporter: ehsan.akhgari, Assigned: valentin)

References

(Depends on 4 open bugs, Blocks 3 open bugs, Regressed 1 open bug)

Details

(4 keywords, Whiteboard: [necko-triaged][adv-main90-])

Attachments

(8 files, 1 obsolete file)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

FTP is an insecure protocol which Blink is considering removing. It seems like we're considering removing support for it on Android but perhaps we should go a step further and remove it completely?

URL: 1438713
See Also: → 1496725
Keywords: site-compat
Flags: needinfo?(honzab.moz)
URL: 1438713
OS: Unspecified → All
Hardware: Unspecified → All
See Also: → 1438713
Duplicate of this bug: 1174462

FTP is still popular in some corners of the web. For example, a majority of the sites hosting the GCC source code use FTP.

It’s little known but all major desktop platforms support FTP with the built-in file manager (Windows: File Explorer, macOS: Finder, Ubuntu Linux: Files) so can we just open the external app?

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #3)

It’s little known but all major desktop platforms support FTP with the built-in file manager (Windows: File Explorer, macOS: Finder, Ubuntu Linux: Files) so can we just open the external app?

Yes, that would be the plan.

(In reply to Botond Ballo [:botond] from comment #2)

FTP is still popular in some corners of the web. For example, a majority of the sites hosting the GCC source code use FTP.

Downloading software source code over an insecure protocol is an extremely dangerous practice, FWIW.

Has anything substantial changed since https://bugzilla.mozilla.org/show_bug.cgi?id=1174462#c25 ?

If this is purely about encryption, then there has been the much longer standing request to add FTPS support. Most FTP servers also offer FTPS (either implicitly or explicitly) so the logical thing would be to add and prefer FTPS.
Also: redirecting a standard FTP request to "whatever the system file manager is" is likely providing less security than even leaving it as-is. There's usually a very good reason that people use a browser or a dedicated FTP client instead of their default file manager for FTP requests.

(In reply to Mark Straver from comment #6)

Has anything substantial changed since https://bugzilla.mozilla.org/show_bug.cgi?id=1174462#c25 ?

This is a hard question to answer since the content of your discussion with Doug wasn't documented on the bug. At this point all of the information available can be found at what's been linked to above so far. I'd expect all of the old objections will be taken into account by the module owners when we get to the point of making a decision here (not sure when that will be).

(In reply to Mark Straver from comment #6)

Has anything substantial changed since https://bugzilla.mozilla.org/show_bug.cgi?id=1174462#c25 ?

Most high-risk downloads are done via https today.

If this is purely about encryption, then there has been the much longer standing request to add FTPS support. Most FTP servers also offer FTPS (either implicitly or explicitly) so the logical thing would be to add and prefer FTPS.

FTPS and HTTPS are often not offered for the same reason. If server operators finally set up Let's Encrypt, they could offer both, if they want.
https://nginx.org/en/docs/http/ngx_http_autoindex_module.html is similar to what web browsers offered in the past.

Also: redirecting a standard FTP request to "whatever the system file manager is" is likely providing less security than even leaving it as-is.

They should add a strong warning and consider disabling insecure connections to public IP addresses by default.

I strongly support removing FTP support completely for security reasons.
FTP is an insecure protocol that we should strongly discourage people from using for anything.

The code is an attack vector and has a long track record of bugs and security issues.
It's very old and mostly written in low-level C code and we support truly archaic systems
by default - FTP servers running on 16-bit Windows etc:
https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/ParseFTPList.h#61
https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/ParseFTPList.cpp#1114

From a security standpoint, I agree with Mats. FTP code is very old, we have found bugs in it before and I don't think it is safe.

However, as long as people are using it, I don't think we should just remove it without having some kind of alternative. Another approach that was discussed before in Necko is to only partially remove support: As Mats pointed out, our FTP implementation supports a broad variety of servers, most of which are likely no longer seen in the wild. We could simplify our FTP implementation to only support was is actually currently used and remove a lot of old archaic code.

This would require a Telemetry probe that is more precise than just protocol usage and ties into the ParseFTPList code.

Isn't there a possibility to write some Javascript code to wrap the ftp connection to being a http(s) download? We would use a better maintained codepath then?

Handing the problem off to GNOME or some other environments doesn't seem to increase security. Those are rather smaller projects with little manpower. Firefox would be the one open source place with the knowledge and the manpower.

Flags: needinfo?(honzab.moz)
Priority: -- → P2
Whiteboard: [necko-triaged]
Depends on: 1579507

Hi. Just a Firefox user. I know this isn't the place for advocacy, but I'm kinda curious about how this bug is going. Google is apparently moving forward with FTP Removal according to this Computer World article [1] and will depreciate FTP with Chrome 80 and according to this gHacks article [2] will remove FTP in Chrome 82. After seeing this news, I checked to see Mozilla's stance on FTP and all I could really find focusing on FTP removal was this bug. I still use FTP from time to time, but if the FTP protocol died off due to security/maintenance concerns, I'm sure I would survive. My point in filing this comment is to ask if Mozilla is going to come up with a unified response on 'what' and 'how' FTP will be handled going forward. When Google does things with Chrome it moves the tech news cycle and it would be a nice thing if those boiler plate news stories could have a blurb at the bottom about Mozilla's plans along side anything from Apple and Microsoft (while its still on a separate code base from Chrome).

[1] https://www.computerworld.com/article/3378017/fast-forward-whats-coming-in-future-versions-of-chrome.html
[2] https://www.ghacks.net/2019/08/16/google-chrome-82-wont-support-ftp-anymore/

Google Chrome 80 disables FTP in February 2020, as per https://developers.google.com/web/updates/2019/12/chrome-80-deps-rems

Type: enhancement → task

Assigning to Mike for decision

Assignee: nobody → mconca
Status: NEW → ASSIGNED
Depends on: 1622335
Depends on: 1622409
Depends on: 1622410

(In reply to ValdikSS from comment #16)

FTP is still widely used

In Firefox, insecure ftp:// is almost unused. This is a web browser. Please use sftp or ftps e.g. with FileZilla for edge cases outside of the web.
If you see a public ftp server, please ask its operator to offer https (and maybe ftps). They need to offer it anyway for other browsers.

You can download and upload whole folders

With Firefox only via HTTP(S).

Keywords: dev-doc-needed
Depends on: 1626365

(In reply to Nhi Nguyen (:nhi) from comment #15)

Assigning to Mike for decision

Decision is made. Unassigning myself and assuming someone on Nhi's team will own this going forward.

Status: ASSIGNED → NEW

When it comes time to flip this pref permanently and remove the underlying code, please ensure that the conditional I just landed for the Windows installer in Bug 1629636 is handled concurrently.

After discussing with :mconca, we are extending FTP support in release until Fx82 due to Covid19. There are at least 600k monthly users who still use it, and Chrome has also re-enabled FTP due to the current situation.

Blocks: COVID-19
Depends on: 1647898

Perhaps when removing FTP support, someone should isolate the code and make it installable as a plug-in or add-on. Of course there should be a big security warning or something when installing it.
I know of several high-traffic websites that primarily use the ftp function of the firefox browser...
Here's an example: ftp://archive.ubuntu.com/
Ubuntu has already made the transition to https, but thousands of other archive sites have not. Browsing files with the ftp protocol is much faster than any webpage, especially since you can't just slap ads or theme garbage on the page.
I just think that it's an extremely bad idea to just dump a useful protocol without making any big announcements about it.

(In reply to Nhi Nguyen (:nhi) from comment #27)

After discussing with :mconca, we are extending FTP support in release until Fx82 due to Covid19. There are at least 600k monthly users who still use it, and Chrome has also re-enabled FTP due to the current situation.

looks like this did not actually happen as I can still access FTP sites with the recently released Firefox 82 beta
also Google plans to remove FTP support entirely starting with Chromium m88 as noted on this page:
https://chromestatus.com/feature/6246151319715840

(In reply to erpman1 from comment #30)

looks like this did not actually happen as I can still access FTP sites with the recently released Firefox 82 beta
also Google plans to remove FTP support entirely starting with Chromium m88 as noted on this page:
https://chromestatus.com/feature/6246151319715840

FTP support has been disabled by default for all Chrome 88 users.
FTP support will be removed from Chrome codebase on Chrome 89.

FYI Chrome's code removal of the feature is being deferred, for details see https://bugs.chromium.org/p/chromium/issues/detail?id=333943#c65 :

Due to this mistake, users who run Chrome without access to our backend infrastructure would've not experienced FTP being disabled until now. Other browser distributions -- notably Chromium -- that pull in //chrome/browser and ship with the default features states are also affected. Out of consideration for those users I'm going to push the code removal to M91. This means that the state of FTP will remain 100% disabled by default for everyone. But the --enable-ftp commandline flag will work for one release longer than originally planned.

(there is even more context at https://chromium.googlesource.com/chromium/src/+/f39d88f50fdcd59a1d6b34628dc2f769e25ce62e)

As of writing, the timeline is:

  • Chrome 88 (released Jan 19, 2021) - disabled by default via a remote configuration (if the server backend wasn't reachable, then ftp was not disabled).
  • Chrome 91 (planned release May 25, 2021) - planned removal of the feature.

(release dates available at https://chromiumdash.appspot.com/schedule)

Depends on: 1691951
Depends on: 1692018

We have small list of things to consider in extensions with the removal of FTP. It would be great if we had at least two releases between prefing off and removing code. That would give us one version on release channel with it disabled before the axe is dropped. Pref off in 88, remove code in 90, possible?

Certainly possible. I'd just like us to remove it before we branch off into esr91, so we don't have annoying merge conflicts when uplifting code.

Depends on: 1699222
Depends on: 1703670
Duplicate of this bug: 1703828
Attachment #9214368 - Attachment is obsolete: true
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/03d34a2f10a6
Stop compiling FTP code r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/b229b0eea1e7
Delete FTP code r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/4a760b3f5d53
Remove ftp prefs r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/ec8c237d5298
Remove FTP proxy code r=necko-reviewers,preferences-reviewers,mixedpuppy,mkaply,dragana
https://hg.mozilla.org/integration/autoland/rev/7ef1884ac11b
Remove FTP error codes r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/9437c60798d6
Fix some failing FTP tests r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/6c2c039872b3
Don't check marionette FTP proxy support in test_session.js r=whimboo,marionette-reviewers
Flags: needinfo?(mconca) → needinfo?(valentin.gosu)
Assignee: mconca → valentin.gosu
Flags: needinfo?(valentin.gosu)
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/b73a08f694ec
Stop compiling FTP code r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/288c44b712b6
Delete FTP code r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/710df44e1a8d
Remove ftp prefs r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/ec8d54876941
Remove FTP proxy code r=necko-reviewers,preferences-reviewers,mixedpuppy,mkaply,dragana
https://hg.mozilla.org/integration/autoland/rev/918cd3aff322
Remove FTP error codes r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/961a320a1d45
Fix some failing FTP tests r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/851056a4d881
Don't check marionette FTP proxy support in test_session.js r=whimboo,marionette-reviewers
https://hg.mozilla.org/integration/autoland/rev/6e22d16b03a3
Remove FTP fuzzer r=necko-reviewers,kershaw
Regressions: 1708196

Docs for this mostly done in https://github.com/mdn/content/pull/5485 - essentially documents removal of feature, preference, and option in the proxy settings. Final work will be a minor update to browser compatibility.

I've set dev-doc-complete, but let me know if there is anything other than the above which needs to be done (a lot of this was cleaned up in FF88)

Is this worth calling out in firefox 90 release notes? (If yes, see https://wiki.mozilla.org/Release_Management/Release_Notes#Nomination_in_Bugzilla)

Flags: needinfo?(valentin.gosu)

Not sure if it's relevant. We could mention that the prefs were removed. bug 1699222 might be worth being included in the release notes.

Flags: needinfo?(valentin.gosu)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #51)

... We could mention that the prefs were removed

there's quite a few "dead?" prefs still lying around

AFAICT these do nothing anymore

  • dom.ipc.plugins.flash.subprocess.crashreporter.enabled
  • dom.ipc.plugins.reportCrashURL
  • plugin.state.flash
  • security.mixed_content.block_object_subrequest ? was this flash only?

Not sure on these ones, there may be others
dom.ipc.plugins.flash.disable-protected-mode ?
plugins.flashBlock.enabled ?
urlclassifier.flash* ?

Flags: needinfo?(valentin.gosu)

Might be worth filing a separate bug for removing those.

Flags: needinfo?(valentin.gosu)

so sorry, I don't know why I brought FLASH up on an FTP issue .. utter failure to read past the first F, lack of sleep, overworked ....

Anyway, filed Bug 1714549

Whiteboard: [necko-triaged] → [necko-triaged][adv-main90-]
You need to log in before you can comment on or make changes to this bug.