> On 18 Dec 2025, at 00:58, Jacob Champion <[email protected]> > wrote: > > On Fri, Dec 12, 2025 at 3:41 AM Daniel Gustafsson <[email protected]> wrote: >>> The comment for HostsLine.ssl_ca, and the code that assigns it, >>> implies to me that host->ssl_ca should never be NULL. Am I missing a >>> case where it could be? >> >> The attached version allows ssl_ca to be omitted from the pg_host config to >> match the ssl_ca GUC. > > Aha! I think ssl_ca should be moved into the "Optional fields" section > of `struct HostsLine` now.
Ah, yes. >> I'm still not sure why they pass for me locally with that error, but I've >> updated to patch to match CI. > > There's one diff remaining from my old tests patch: the example.org > line doesn't set ssl_ca, so I expect > >> - expected_stderr => qr/unknown ca/); >> + expected_stderr => qr/client certificates can only be checked if a >> root certificate store is available/); > > because host_context->ssl_loaded_verify_locations should be false. But > that doesn't happen... Why? I'll have a look. > Just checking my understanding: is the use case for no_sni primarily > that you should be able to strictly refuse clients who say they're > talking to someone else -- so you don't want a wildcard -- but you > still want to gracefully handle clients who don't speak SNI at all? Yeah, pretty much. >> + else if (strcmp(host->hostname, "no_sni") == 0) >> + no_sni_context = host_context; > > Will anyone be mad at us for camping on the "no_sni" identifier? I > know technically underscore isn't allowed in DNS hostnames, buuuut [1, > 2] Maybe, but I think that regardless of what we do someone will be mad. The other option would be to use another single character like '?' or something. Not sure that will improve readability though. >> + /* Hostname */ >> + field = list_head(tok_line->fields); >> + tokens = lfirst(field); >> + token = linitial(tokens); >> + parsedline->hostname = pstrdup(token->string); > > We should probably check tokens->length to make sure that the user > hasn't passed more than one token for each field, similar to how > parse_hba_line() does it. Good point, will do that. > Should we support multiple hostname tokens in a single line, though, > and just copy the settings that follow across all of them? I've been hesitant to add too much complexity, but perhaps just allowing a comma separated list is a good middle ground to avoid going full regex? -- Daniel Gustafsson
