mirror of
https://github.com/netbirdio/netbird.git
synced 2026-10-10 07:29:06 +02:00
The error-vs-"no KEM" ambiguity fixed on the answer path also existed on the offer path: when SignalOffer failed to build the bootstrap offer (e.g. an entropy failure in startExchangeLocked), OfferPayload logged it and still sent an empty MlkemPayload. The responder read that as "peer does not run the KEM", marked the initiator non-capable, and answered empty — which made the initiator mark the responder non-capable too, disabling the KEM for the session over one transient error. Return the MsgError marker from SignalOffer on failure, and have the responder's SignalOnOffer answer a received marker with its own marker rather than an empty answer. A genuinely non-KEM peer still sends no payload at all, so the empty capability signal is unchanged. Found in cubic review on #7098 (client/internal/pqkem_adapter.go:130).