Draft: Bug 0.4.5.5-rc ORPort relay (using both IPv4 & IPv6)

For #40289 (closed)

changed milestone to %Tor: 0.4.5.x-stable

changed the description

mentioned in issue #40289 (closed)

If we're going to do the comparison like this, we need to make 100% sure that there aren't any uninitialized padding bytes or pointers in port_cfg_t or its members.

I think this comparison will also Do The Wrong Thing if unix_addr is set in port_cfg_t. That doesn't happen for or listeners, but we should document that limitation.

If you do keep this implementation, it MUST NOT use sizeof(port_cfg_t). It has to use offsetof(port_cfg_t, unix_addr) instead, because FLEXIBLE_ARRAY_MEMBER is an ugly hack that can sometimes be 1 on obsolete compilers. If it is, then we can wind up allocating port_cfg_t objects that are smaller than sizeof(port_cfg_t).

changed this line in version 2 of the diff

Fixup: 344b6b49

This looks okay to me, except that the implementation of port_cfg_eq() is potentially error-prone. Please either change that function to do a field-by-field comparison, or make sure that we never have uninitialized bytes in a port_cfg_t?

Also please see the note about the size of port_cfg_t.

added Needs Revision label

added 1 commit

• 344b6b49 - fixup! config: Do not compare for duplicate ORPorts with different addresses

Compare with previous version

marked this merge request as draft from dgoulet/tor@344b6b49

removed Needs Revision label

added 1 commit

• fbb1f02f - fixup! fixup! config: Do not compare for duplicate ORPorts with different addresses

Compare with previous version

lgtm; please merge when you're ready.

closed