Replace silent kv_extend normalisation with an unconditional 400. RFC 9112 5.2 explicitly permits rejection; it is the safer choice over SP replacement, which hides parser ambiguity downstream.

While there, add error checks for X509_set_{pubkey,issuer_name}(). From Marc Jorge

relayd is missing this method from the WebDAV/CalDAV extensions. This causes issues when using relayd as a reverse proxy in front of CalDAV servers like Nextcloud. OK kirill@

feedback and OK tb@

relayd supports interface name, DNS hostname or interface group at listen on but it binds only to the first discovered IP address which is usually IPv4. Here I changed parser to create a dedicated listener for each discovered and confiugred on a local inerface address. This means that listen on egress port 80 binds to all IPv4 and IPv6 addresses on the egress group. OK: rsadowski@

RFC 9112 section 6.3 specifies that responses to HEAD requests, and responses with 1xx, 204, or 304 status codes, are terminated by the empty line after the header section regardless of Content-Length or Transfer-Encoding. They cannot contain a message body or trailer section. Teach relayd to apply that framing rule before deciding whether a response body is bounded. Otherwise relayd treats these responses as unbounded, adds Connection: close, and can forward both the backend's Connection: keep-alive and its own Connection: close. Tweaks and OK: rsadowski@

This replaces bzero with explicit_bzero in the SSL password callback. Since ssl_password_cb handles sensitive data a standard bzero could be optimized away by the compiler. Additionally, this ensures the buffer is cleared if strlcpy fails due to truncation, preventing password fragments from lingering in memory. OK renaud@, kirill@

Extend the "keypair" keyword in relayd.conf to support optional explicit paths. Previously, relayd enforced a naming convention, looking up files in /etc/ssl and /etc/ssl/private based on the keypair name. This change allows other applications to manage their certificates without having to comply with relayd's internal naming logic. Input and OK kirill@, help form tb@

Fix a bug in relay_inherit() which runs only relay_load_certfiles(conf, rb, NULL) unconditionally which isn't alligned with logic in parser when it parses relay block, where multiple certificates are load as relay_load_certfiles(conf, rb, NULL) only if here no tlscerts (for default host) and otherwise it loads keypairs. OK: rsadowski@

original diff from CypherFox (openbsd at cypher-fox com), thanks! slightly rearranged to be a bit smaller by me, but still equivalent.

it's already closed and fd set to -1 a few lines above. diff from Marc Jorge (openbsd [at] cypher-fox com), thanks!

If the second tls_cfg_new() call fails, the tls_cfg is leaked. From Jan Schreiber

If relay_httperror_byid() is passed a HTTP error code not in the table this would result in a NULL deref. The intent is that the code fall back to "Unknown error" on NULL return. From Jan Schreiber

Due to a copy-paste error, relay_lookup_query() would check the wrong kv member for NULL. From Jan Schreiber

This is a structural refactoring with no functional change. OK kirill

Instead of terminating with fatalx() when a private key hash cannot be found, log a warning and send an error back to the relay worker. This prevents a race condition during "reload" where a request might reach the CA process while keys are being repopulated. Reported by Nick Owens; thanks! OK tb@

Adjust a comment. Being non-existent, the OpenSSL engine layer cannot be responsible for whatever unholy hacks this code requires.

Joel Carnat (Thanks) notice that GoToSocial does not like it when we sent no User-Agent and returns an HTTP/418. Lloyd pointed to use RELAYD_SERVERNAME instead hardcoded "relayd" OK sthen, claudio (diff without RELAYD_SERVERNAME)

OK claudio@

OK claudio@

If the cookie doesn't match, we bail with a continue and totally forget to free the imsg. OK claudio@

patch from Christoph Liebender OK: rsadowski@

The things that need quoting are not necessarily "argument names", and not even necessarily "names" at all, so just talk about "arguments". "I guess?" florian@ and no objection from otto@, both back in July 2025. Actually, the quoting rules are more complicated than the text makes believe, but i do not know how to better describe them. It may not be easy because some suspect the implementation may be somewhat adhoc rather than based on cleary defined lexical rules.