On Tue, Feb 24, 2026 at 07:52:16AM +0100, Rafael Sadowski wrote:
> If imsg_composev() or imsgbuf_flush() fail, the message was never sent
> to the CA process. Without return -1, poll() waits for the full timeout
> for a response that can never come and blocks the event loop of the
> relay worker.
> 
> Or what is the intention?  Comment in code:
> 
>    * Send a synchronous imsg because we cannot defer the RSA
>    * operation in OpenSSL's engine layer.
> 
> Can we do better these days? As I understand it, the poll is the sync
> workaround here.
> 
> Index: ca.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/relayd/ca.c,v
> diff -u -p -r1.46 ca.c
> --- ca.c	24 Feb 2026 06:03:29 -0000	1.46
> +++ ca.c	24 Feb 2026 06:45:53 -0000
> @@ -335,10 +335,14 @@ rsae_send_imsg(int flen, const u_char *f
>  	 * Send a synchronous imsg because we cannot defer the RSA
>  	 * operation in OpenSSL's engine layer.
>  	 */
> -	if (imsg_composev(ibuf, cmd, 0, 0, -1, iov, cnt) == -1)
> +	if (imsg_composev(ibuf, cmd, 0, 0, -1, iov, cnt) == -1) {
>  		log_warn("%s: imsg_composev", __func__);
> -	if (imsgbuf_flush(ibuf) == -1)
> +		return -1;
> +	}
> +	if (imsgbuf_flush(ibuf) == -1) {
>  		log_warn("%s: imsgbuf_flush", __func__);
> +		return -1;
> +	}
>  
>  	pfd[0].fd = ibuf->fd;
>  	pfd[0].events = POLLIN;
> 

OK claudio@. I doubt you can hit those cases in production. When I rewrote
this code long time ago I had busy relayd instances and they ran into
issues all the time until I fixed this code.
At some point there was a plan to real hooks in libtls to do this key
separation possible without these insane engine hacks. I have lost track
on where that project was left.

-- 
:wq Claudio