IP-based SAN support

[pgguru]

The existing SAN code only recognizes DNS-based SANs, which means that it won't properly validate if using a SAN with an IP-based one. This PR adds support for IPv4, and if the OS supports it, IPv6. The current support is exact matching only.

This support would have simplified testing in a few occasions where many cert generation tools have trouble generating a DNS:1.2.3.4-style address, preferring to include the SAN as IP:1.2.3.4.

Needs tests, but this is POC of the feature.

[pgguru]

Some (not unexpected) issues with how some OSes detect inet_aton; if it ends up being super problematic we might just write the mapping ourselves. (AFAIK we're just using it to help w/byte ordering, so can probably use existing C macros for the same effect.)

[pgguru]

And doing a little more research on this, looks like inet_pton can also map IPv4 addresses; we followed what Postgres does here as far as the IP SAN resolution, and they'd determined they needed additional flexibility in representation for IPv4 that inet_aton() supports. I do wonder if that is actually needed though and if we could get away with inet_pton(AF_INET) for IPv4 as well; would simplify this feature.

[dwsteele]

And doing a little more research on this, looks like inet_pton can also map IPv4 addresses; we followed what Postgres does here as far as the IP SAN resolution, and they'd determined they needed additional flexibility in representation for IPv4 that inet_aton() supports.

It might be worth checking with the author of that patch so see what their motivation was. I don't have a strong opinion either way. If we use inet_aton we'll need to grab the configure/meson code that makes inet_aton/inet_pton work. Defining _GNU_SOURCE here is not going to work (yes, I get that this is temporary).

[pgguru]

And doing a little more research on this, looks like inet_pton can also map IPv4 addresses; we followed what Postgres does here as far as the IP SAN resolution, and they'd determined they needed additional flexibility in representation for IPv4 that inet_aton() supports.

It might be worth checking with the author of that patch so see what their motivation was. I don't have a strong opinion either way. If we use inet_aton we'll need to grab the configure/meson code that makes inet_aton/inet_pton work. Defining _GNU_SOURCE here is not going to work (yes, I get that this is temporary).

Yeah, looks like it was Peter E; will shoot him an email.

[pgguru]

No response from him yet at this point; here's what the man page says:

Unlike inet_aton(3) and inet_addr(3), inet_pton() supports IPv6
addresses. On the other hand, inet_pton() accepts only IPv4
addresses in dotted-decimal notation, whereas inet_aton(3) and
inet_addr(3) allow the more general numbers-and-dots notation
(hexadecimal and octal number formats, and formats that don't
require all four bytes to be explicitly written). For an
interface that handles both IPv6 addresses, and IPv4 addresses in
numbers-and-dots notation, see getaddrinfo(3).

From these docs, I'm not seeing something that seems overly restrictive by just using inet_pton(). Do you see anything more concerning here?

[dwsteele]

I think it looks reasonable to just use inet_pton(). It is in the Posix 2001 spec so should be supported on all the systems we test on. Give it a try and see how it goes, i.e. remove HAVE_INET_PTON and see if anything breaks without requiring a configure check.

[pgguru]

Okay, tweaked that and fixed a few other things; looks like it's at least compiling without complaints, which is a start... 😁. Will review after existing checks run.

[pgguru]

@dwsteele looks like everything is happy but code coverage now.

[dwsteele]

Yeah, looks like coverage is next. The main test cert will need to be rebuilt, see test/certificate/README.md.

Then we'll need some new tests right around line 610 in ioTlsTest.c.