]> git.ipfire.org Git - thirdparty/FORT-validator.git/commit
Remove > 65535 validation from --server.port
authorAlberto Leiva Popper <ydahhrk@gmail.com>
Wed, 7 Feb 2024 19:08:09 +0000 (13:08 -0600)
committerAlberto Leiva Popper <ydahhrk@gmail.com>
Thu, 8 Feb 2024 20:24:17 +0000 (14:24 -0600)
commit94a83715c2ed483d65cec6a76f258d830a6991fa
tree1f9917c3fbdffda7b50bc93b9527619fde30da04
parentfe3967e2f10c1b0b022c8c83557cf9b714a56892
Remove > 65535 validation from --server.port

While trying to implement the upcoming patch, I found myself trying to
refactor this validation. The implementation was awkward; instead of
ntohs'ing sockaddr_in.sin_port, it extracted the bytes manually:

port = (unsigned char)((*result)->ai_addr->sa_data[0]) << 8;
port += (unsigned char)((*result)->ai_addr->sa_data[1]);

But on second thought, I'm not seeing this validation eye to eye.
It's intended to prevent `getaddrinfo()` from parsing
`--server.port=120000` like `--server.port=54464` (120000 % 65536) on
Linux, but... thing is, this "port out of bounds" quirk looks like an
everyday Linux idiosyncrasy.

Linux being Linux:

$ nc -lv 127.0.0.1 120000
Listening on localhost 54464

It's weird but seems inoffensive, and some beardos might even expect it.

`getaddrinfo()` returns proper errors in the BSDs, so the validation is
redundant there.
src/rtr/rtr.c