bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

["Ludovic Courtès" <ludo@gnu.org>]

Ludovic Courtès <ludovic.courtes@inria.fr> skribis:

> The ‘cuirass remote-server’ process goes awry when misbehaved clients
> connect; specifically, some of its fibers crash, leaving it running but
> inactive:
>
> 2023-12-04 10:13:14 periodic update: 0 resumable, 0 failed builds
> 2023-12-04 10:13:28 error: Connection reset by peer when replying to xx.xx.xx.254.
> 2023-12-04 10:13:42 error: invalid log received from xx.xx.xx.254
> 2023-12-04 10:13:42 error: EOF while receiving log from xx.xx.xx.254
> 2023-12-04 10:13:48 Uncaught exception in task:
> 2023-12-04 10:13:48 In fibers.scm:
> 2023-12-04 10:13:48    186:20  8 (_)
> 2023-12-04 10:13:48    145:21  7 (_)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1752:10  6 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
> 2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
> 2023-12-04 10:13:48    695:11  5 (_)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1747:15  4 (with-exception-handler #<procedure 7f982c2abd50 at ice-9/boot-9.scm:1831:7 (exn)> _ #:unwind? _ #:unwind-for-type _)
> 2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
> 2023-12-04 10:13:48    437:23  3 (serve-build-requests _ #<<channel> getq: #<atomic-box 7f982e764390 value: (() #(#<atomic-box 7f98283753a0 value: W> #<procedure resume (thunk)>))> getq-gc-co
> unter: #<atomic-box 7f982e764320 value: 16> putq: #<atomic-box 7f982e764240 value: (())> putq-gc-counter: #<atomic-box 7f982e764230 value: 31>>)
> 2023-12-04 10:13:48 In cuirass/remote.scm:
> 2023-12-04 10:13:48     466:6  2 (receive-message _ #:router? _)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1685:16  1 (raise-exception _ #:continuable? _)
> 2023-12-04 10:13:48   1685:16  0 (raise-exception _ #:continuable? _)
> 2023-12-04 10:13:48 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> 2023-12-04 10:13:48 Throw to key `match-error' with args `("match" "no matching pattern" (#<zmq-message 7f981881d9a0> #<zmq-message 7f981881d900> #<zmq-message 7f981881d860>))'.

With commit 9a1452ee021c9f773424961cfeef47ca0b7c5c5a, ‘cuirass
remote-server’ handles this situation gracefully.

I’m still curious about who’s sending us garbage: it has to be valid
zmq, just with the wrong number of parts.  From the logs, it seemed like
a port scanner or something on the MDC network was sending garbage on
all the open ports, but that would need to be a sophisticated one.

Ludo’.