-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ftp proxy support? #16901
Comments
FTP should be considered deprecated and should not be added to Envoy - https://developers.google.com/web/updates/2019/12/chrome-80-deps-rems |
im not sure the protocol is deprecated just because chromium no longer supports it - i think there are still use cases for it (altho tbh i personally havent used it for some time) |
eg - package distribution - https://wiki.debian.org/FTP |
We know from analysis that Curl is bad news from a security, CVE and dependency point of view. We want to remove Curl - #11816. Whether ftp is considered deprecated or not, we should not enable it in core Envoy for similar reasons |
im not sure the two are comparable one is a tool (and lib) the other is protocol |
I think that chrome no longer supports FTP does not mean that FTP is abandoned. The reason why Chrome does not support FTP is quite ok. Nowadays, browsers are indeed used less and less to access ftp server.
But the FTP protocol itself is still widely used in many places. I don't quite understand why it is related to Curl lib. The two seem to be incomparable. As @phlax said, one is the protocol and the other is the library. |
The point of raising curl was not to say it was equivalent to FTP. Assuming that an existing library would be used for FTP, it would introduce a new dependency. FTP is a protocol but in order for Envoy to support it, wouldn't a library / code be required to implement it? As outlined in https://envoycon2020.sched.com/event/ecdA/understanding-maintaining-and-securing-envoys-supply-chain?linkback=grid-full, curl represents the largest concentration of CVE's that impact Envoy. There could be a bulletproof, fuzzed and well maintained FTP library with a CVE track record we could use. But as curl has demonstrated (and Envoy as well) building secure networking code is difficult. FTP could be enabled as an extension and compartmentalized. A new extension would need to follow the policy at https://github.com/envoyproxy/envoy/blob/main/EXTENSION_POLICY.md. And the introduction of new dependencies needs to follow the policy at https://github.com/envoyproxy/envoy/blob/main/DEPENDENCY_POLICY.md |
The FTP protocol is actually quite simple (although its network model is slightly more complicated). So I think we may not need to introduce new deps. |
Yes, adding new extensions must of course conform to the community's norms. This issue is just to understand the wishes of the community and the possibility of adding ftp support. |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
Envoy supports proxy various protocols, http, kafka, redis, mq and so on. I wonder if it is possible to add another ftp proxy to envoy?
haproxy supports the ftp protocol, but only supports passive mode. Envoy may be able to do better. 🤔
The text was updated successfully, but these errors were encountered: