From: Claudio Jeker Subject: Re: relayd: check imsg_composev() / imsgbuf_flush() fail To: Rafael Sadowski Cc: tech@openbsd.org Date: Tue, 24 Feb 2026 11:22:32 +0100 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