Created attachment 177106 [details]
Example file with hyperlink to a public FTP site
Currently creation and opening of FTP hyperlinks is supported in LibreOffice.
Given that this is an inherently insecure protocol, LO should drop support for it in the Hyperlink dialog and the ucp backend as well.
The ODF standard does not require support of this protocol, so that's not a concern.
Recently popular browsers stopped supporting the FTP protocol citing security concerns and low usage of the protocol in browsers  .
Created attachment 177107 [details]
The example document and Hyperlink dialog in current master
Caolan, what's your take on this?
I don't have any particular opinion here. I don't hold any affection for ftp and it is obscure at this point and one less thing to support sounds good to me. Maybe its worth mentioning it at an ESC (or on the mailing list) so the proposed removal is flagged.
With the same reasoning you could drop HTTP support as it is inherently insecure.
Note what the chrome link says:
"The current FTP implementation in Google Chrome has no support for encrypted connections (FTPS), nor proxies. Usage of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client."
So they just did not want to implement FTPS support.
As we now use curl, couldn't we take advantage of it and only allow FTPS in the ucp stuff? https://everything.curl.dev/ftp/ftps
We discussed the proposal at the ESC meeting and there are no concerns to remove the protocol.
(In reply to Buovjaga from comment #4)
> As we now use curl, couldn't we take advantage of it and only allow FTPS in
> the ucp stuff?
Why invest effort here when it's most likely not used by anyone.
Then announce it as deprecated in 7.3 release notes.
Asking as a user (from a user perspective):
What exactly is the problem, if LO supports embedding FTP **links** in documents? As far as I can tell, clicking on such a link will just open an external FTP program, and that only, if one is actually installed on the users computer.
AFAIK, web browsers have only removed the ability to open/view FTP links **directly in the browser**. FTP links (that open in an external application) are still supported.
I'd agree, that LO probably doesn't need the ability to connect to FTP servers itself (if such ability actually exists in LO). But I'd also like to ask: Is it's really the responsibility/job of a word processor to prevent users from embedding links of certain types into their documents? It feels like an artificial limitation. A bit patronizing even. IMHO users should be allowed to embed any type of link they choose.
(In reply to Damian Hofmann from comment #7)
> What exactly is the problem, if LO supports embedding FTP **links** in
> documents? As far as I can tell, clicking on such a link will just open an
> external FTP program, and that only, if one is actually installed on the
> users computer.
> But I'd also like to ask: Is it's really the responsibility/job of a word
> processor to prevent users from embedding links of certain types into their
> documents? It feels like an artificial limitation. A bit patronizing even.
> IMHO users should be allowed to embed any type of link they choose.
I suppose that the wording of the Gabor's proposal is a bit misleading; and also this issue combines several:
1. Remove the "FTP" protocol radiobutton (and hence the whole Protocol section) from the Hyperlink dialog ; *assume* HTTP *when user does not provide the schema explicitly* in the URL - but as before, accept any explicitly passed schema.
2. Remove the FTP option from Open Remote/Save Remote .
3. Remove the possibility to e.g. link to external data from Calc (like Sheet->Link to External Data , or WEBSERVICE spreadsheet function ).
Also I suppose that ESC decision was about #2 and #3.
(In reply to Mike Kaganski from comment #8)
I'm sure it will break someones existing workflow if you remove FTP support for external data linking and "Open/Save remove". But I can also see, why FTP shouldn't be used at this point.
Still, I think some users will be caught on the wrong foot, if you just "announce" it deprecated and then remove it. Very few user read the release notes. Maybe consider a multi-step approach:
1. Disable the feature by default, but allow it to be enabled in the settings for some time
1. Show the deprecation notice there in the settings, so that users who depend on these features (and have to re-enable it) can't miss it
1. Remove in a later version
I don't use these features myself, so I'm not personally affected. I'm fine, as long as I can embed links of any protocol in my documents and those links open with the default application, as configured in the OS. I don't even need the "Insert Hyperlink" dialog to assist me. A simple dialog with "link text" and "URL" would be good enough for me.
(In reply to Buovjaga from comment #6)
> Then announce it as deprecated in 7.3 release notes.
We missed this boat, so looks like support can be dropped only with 7.5 release. Is someone going to add a deprecation note for 7.4 or will I do it?
It sounds like a good idea for you to go ahead and add a deprecation note for 7.4 so if someone picks up this task before 7.4 they won't be tripped up by the lack of that, and no great harm if it rolls over.
(In reply to Caolán McNamara from comment #11)
> It sounds like a good idea for you to go ahead and add a deprecation note
> for 7.4 so if someone picks up this task before 7.4 they won't be tripped up
> by the lack of that, and no great harm if it rolls over.
Master is now 7.5, so dropping FTP support can be done per the polite deprecation notice in 7.4 notes.