The SSL support in net-ftp/ftp disobeys RFC 2228 (http://www.faqs.org/rfcs/rfc2228.html). Excerpt: "DATA CHANNEL PROTECTION LEVEL (PROT) The argument is a single Telnet character code specifying the data channel protection level. This command indicates to the server what type of data channel protection the client and server will be using. The following codes are assigned: C - Clear S - Safe E - Confidential P - Private The default protection level if no other level is specified is Clear." This gets further clarified in RFC 4217 (although for AUTH TLS) (http://www.ietf.org/rfc/rfc4217.txt): "Initial Data Connection Security The initial state of the data connection MUST be 'Clear' (this is the behaviour as indicated by [RFC-2228])." Please note that there is no official specification specifically for AUTH SSL. net-ftp/ftp however does not issue any PROT command, yet assumes the data connection to be SSL secured. This does not work with standard-compliant servers which follow RFC 2228 (and RFC 4217). This gets further complicated by the fact that many broken servers deliberately disobey RFC 2228 as well and chose to make PROT P the implicit default. The most compatible solution is to issue the "PBSZ 0" command followed by "PROT P" (or "PROT C", depending on the user's choice) after the AUTH SSL command. This ensures that both standard-compliant as well as broken servers are in the same state after login. Reproducible: Always
Shrug; this patch doesn't come from Gentoo... Maybe this one does what you want. http://ftp.debian.org/debian/pool/main/n/netkit-ftp-ssl/netkit-ftp-ssl_0.17.12+0.2-6.diff.gz
i'd just as soon punt this patch if it's problematic since the netkit-ftp stuff is unmaintained at this point
Jakub, the patch from Debian still would not work, it only issues the PROT command after a fallback to AUTH TLS should AUTH SSL fail. Simply removing the "if (use_tls)" check should make it work though.
Tim: please produce a new patch instead then, and reopen with it. Alternatively, get the upstream doing stuff...
