bug#46342: 28.0.50; socks-send-command munges IP address bytes to UTF-8

["J.P." <jp@neverwas.me>]

Eli Zaretskii <eliz@gnu.org> writes:

> Then they are what we call "raw bytes", and encoding them with
> raw-text-unix should suffice.

Thanks. Unfortunately, this produces the same utf-8 encoded bytes.

  (encode-coding-char 192 'raw-text-unix)
  ⇒ "\303\200"
  
It looks like raw-text-unix is an alias for binary [1], the coding
system already used by the network process sending the erroneous
request. I suppose it's always possible to strong arm it like

  (encode-coding-char (or (decode-char 'eight-bit c) c) 'raw-text-unix)
  ⇒ "^@" ... "\377"

But what about your original latin-1 suggestion? Is that no longer in
contention?

  (encode-coding-char 192 'latin-1)
  ⇒ "\300"

> How does the code which calls socks.el create these raw bytes?

This library has an entry-point function that's part of the url-gateway
dispatch mechanism. I can't say for certain, but it looks like url-http
is the only library directly using this facility. Regardless, the
function gets called with a (possibly multibyte) host name, which in
rare cases may be an ASCII IP address created by url-gateway.

With SOCKS4, that's kind of moot, since all names are looked up through
socks-nslookup-host, which returns an IPv4 address as a list of fixnums.
Its caller is an internal helper that converts this list into a
multibyte string for socks-send-command to emit onto the wire (where
it's then rejected by the service).

Currently, IP addresses aren't used at all for v5 connect-command
requests. And raw-byte IP addresses do not yet appear anywhere [2]. This
patch would introduce them, either as an argument to socks-send-command
or as something ephemeral produced by it (the current idea).


[1] (elisp) Coding System Basics
[2] Of course, these are generalities that don't apply to users who wire
everything up manually.