Re: [patch] netcat: support --crlf
Hi op. On Fri, 25 Aug 2023 20:14:37 +0200 Omar Polo wrote: > On 2023/08/25 09:07:35 -0600, "Theo de Raadt" wrote: > > Pietro Cerutti wrote: > > > > > The motivation is that several network protocols are line oriented > > > with CRLF as line terminators. SMTP and HTTP are among the most > > > popular. > > > > Yet, all servers of those protocols and and will accept the simpler 1-byte > > line terminator. > > Not http at least. Try nc www.openbsd.org 80 and type an http > request, httpd(8) will be happily waiting for a \r. > > opensmtpd is less picky and is happy with just a line feed. > > (I don't have any opinion on adding a flag. To be fair, even if it > were added I would probably forget and just use ^V^M^M instead of RET > to terminate the lines when manually testing something.) > I don't have any skin in this game. However, It's obvious to me that nc shouldn't deal with protocol-specific things and adding flags to it to accomodate such behaviour just feels wrong. Netcat is, purely, a transport tool, it is not netcat business if a bunch of bytes written in it's stdin, or whatever, terminates with '\r\n', or just '\n'.
Re: [patch] netcat: support --crlf
On 2023/08/25 09:07:35 -0600, "Theo de Raadt" wrote: > Pietro Cerutti wrote: > > > The motivation is that several network protocols are line oriented > > with CRLF as line terminators. SMTP and HTTP are among the most > > popular. > > Yet, all servers of those protocols and and will accept the simpler 1-byte > line terminator. Not http at least. Try nc www.openbsd.org 80 and type an http request, httpd(8) will be happily waiting for a \r. opensmtpd is less picky and is happy with just a line feed. (I don't have any opinion on adding a flag. To be fair, even if it were added I would probably forget and just use ^V^M^M instead of RET to terminate the lines when manually testing something.)
Re: [patch] netcat: support --crlf
On Fri, Aug 25, 2023, Theo de Raadt wrote: > Pietro Cerutti wrote: > > The motivation is that several network protocols are line oriented > > with CRLF as line terminators. SMTP and HTTP are among the most > > popular. > Yet, all servers of those protocols and and will accept the simpler 1-byte > line terminator. That is incorrect. Some SMTP servers will insist on CRLF as line ending, esp. when it comes to EOM. -- Address is valid for this mailing list only, please do not reply to it directly, but to the list.
Re: [patch] netcat: support --crlf
Pietro Cerutti wrote: > The motivation is that several network protocols are line oriented > with CRLF as line terminators. SMTP and HTTP are among the most > popular. Yet, all servers of those protocols and and will accept the simpler 1-byte line terminator. > FWIW, it works on RHEL 7.9 That isn't based on our nc. It is a replacement tool with other options. There is no standard, instead there are 4-5 tools with the same name and an increasing number of incompatible options. People just can't resist adding incompatible changes and extensions. We ourselves added a bunch of new TLS-related options because "openssl s_client" is COMPLETELY UNSUITABLE FOR ANY USE BECAUSE OF the "line begins with R or Q" behaviour. I'm not sure where all of this will go in the long term, but noone seems to want act like they desire convergence. I'll predict that option/capability convergence is less likely than one of them eventually shipping with a built-in extension langauge (like maybe a lisp, or one of the many incompatible BPF extensions that are all the rage).
Re: [patch] netcat: support --crlf
On Aug 24 2023, 01:02 UTC, Damien Miller wrote: On Wed, 23 Aug 2023, Pietro Cerutti wrote: Hi, here at FreeBSD, we vendor in your netcat with a few local modifications. I'm working on adding support to --crlf. I have a diff against the FreeBSD version here: https://reviews.freebsd.org/D41489 I'd like this to be upstreamed. If there's consensus, I'll prepare a patch against OpenBSD's version and send it over. What is the motivation for this option beyond "Linux has it"? The motivation is that several network protocols are line oriented with CRLF as line terminators. SMTP and HTTP are among the most popular. I don't come from Linux so "Linux has it" was not among my motivations. Correct me if I'm wrong but it seems trivial to do this conversion without writing more code by sticking tr in a pipe with nc. Can you please provide an example? I can't see how to make tr convert LFs not preceeded by CRs to CRLFs. OpenBSD's nc doesn't use getopt_long at present and I'm not sure there would be appetite to do it for a single new flag. I note that nc on the Debian machine I have at hand does -C but doesn't recognise --crlf. IMO the long option therefore just adds incompatibility. That's a fair point - I should have noticed that. If you want the feature, we can pick a new short option and I'm happy to make the FreeBSD version compatible with that. [djm@dvm ~]$ nc --crlf nc: invalid option -- '-' usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl] [-m minttl] [-O length] [-P proxy_username] [-p source_port] [-q seconds] [-s sourceaddr] [-T keyword] [-V rtable] [-W recvlimit] [-w timeout] [-X proxy_protocol] [-x proxy_address[:port]] [destination] [port] [djm@dvm ~]$ uname -a Linux dvm 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64 GNU/Linux FWIW, it works on RHEL 7.9 -- Pietro Cerutti I have pledged to give 10% of income to effective charities and invite you to join me - https://givingwhatwecan.org
Re: [patch] netcat: support --crlf
On Wed, 23 Aug 2023, Pietro Cerutti wrote: > Hi, > > here at FreeBSD, we vendor in your netcat with a few local modifications. > > I'm working on adding support to --crlf. I have a diff against the FreeBSD > version here: https://reviews.freebsd.org/D41489 > > I'd like this to be upstreamed. If there's consensus, I'll prepare a patch > against OpenBSD's version and send it over. What is the motivation for this option beyond "Linux has it"? Correct me if I'm wrong but it seems trivial to do this conversion without writing more code by sticking tr in a pipe with nc. OpenBSD's nc doesn't use getopt_long at present and I'm not sure there would be appetite to do it for a single new flag. I note that nc on the Debian machine I have at hand does -C but doesn't recognise --crlf. IMO the long option therefore just adds incompatibility. [djm@dvm ~]$ nc --crlf nc: invalid option -- '-' usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl] [-m minttl] [-O length] [-P proxy_username] [-p source_port] [-q seconds] [-s sourceaddr] [-T keyword] [-V rtable] [-W recvlimit] [-w timeout] [-X proxy_protocol] [-x proxy_address[:port]] [destination] [port] [djm@dvm ~]$ uname -a Linux dvm 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64 GNU/Linux -d
[patch] netcat: support --crlf
Hi, here at FreeBSD, we vendor in your netcat with a few local modifications. I'm working on adding support to --crlf. I have a diff against the FreeBSD version here: https://reviews.freebsd.org/D41489 I'd like this to be upstreamed. If there's consensus, I'll prepare a patch against OpenBSD's version and send it over. Thanks, -- Pietro Cerutti I have pledged to give 10% of income to effective charities and invite you to join me - https://givingwhatwecan.org
