Summary
In Peer, both certificate paths set certificatesValidated = true, persist the session, and resolve the certificate-validation waiters before awaiting the onCertificatesReceived listeners. A listener that throws therefore cannot prevent the session from being treated as validated.
Found while porting @bsv/sdk 2.4.1 certificate handling to Rust.
Detail
The ordering in processInitialResponse → validateInitialResponseCertificates is:
certificatesValidated = trueupdateSession(...)resolveCertificateValidation(sessionNonce)for (const callback of this.onCertificatesReceivedCallbacks.values()) { await callback(...) }
processCertificateResponse has the same order.
Since the listeners are awaited after the commit and after the waiters are released, a listener that rejects aborts the remaining listeners and propagates out of handleIncomingMessage — but the session state has already been committed, and anything blocked in processGeneralMessage waiting on certificate validation has already been released.
Impact
onCertificatesReceived reads naturally as a place to apply application-level acceptance policy — inspect the certificates, throw to reject the peer. It cannot serve that purpose: by the time it runs, the decision is made and general-message traffic is already unblocked.
Applications that want to gate on certificate content have to do it elsewhere, and there is currently nothing in the API surface signalling that.
Suggested fix
Either await the listeners before committing certificatesValidated and resolving waiters, so a rejection can veto the session — or document explicitly that onCertificatesReceived is an observer and cannot reject.
The first is a behaviour change (a slow listener would delay validation); the second is free. Either is better than the current ambiguity.
Note
We conformed to the current ordering in our port rather than diverging, and documented it as a known upstream behaviour, on the principle that a silent cross-language divergence is worse than a shared quirk.
Summary
In
Peer, both certificate paths setcertificatesValidated = true, persist the session, and resolve the certificate-validation waiters before awaiting theonCertificatesReceivedlisteners. A listener that throws therefore cannot prevent the session from being treated as validated.Found while porting
@bsv/sdk2.4.1 certificate handling to Rust.Detail
The ordering in
processInitialResponse→validateInitialResponseCertificatesis:certificatesValidated = trueupdateSession(...)resolveCertificateValidation(sessionNonce)for (const callback of this.onCertificatesReceivedCallbacks.values()) { await callback(...) }processCertificateResponsehas the same order.Since the listeners are awaited after the commit and after the waiters are released, a listener that rejects aborts the remaining listeners and propagates out of
handleIncomingMessage— but the session state has already been committed, and anything blocked inprocessGeneralMessagewaiting on certificate validation has already been released.Impact
onCertificatesReceivedreads naturally as a place to apply application-level acceptance policy — inspect the certificates, throw to reject the peer. It cannot serve that purpose: by the time it runs, the decision is made and general-message traffic is already unblocked.Applications that want to gate on certificate content have to do it elsewhere, and there is currently nothing in the API surface signalling that.
Suggested fix
Either await the listeners before committing
certificatesValidatedand resolving waiters, so a rejection can veto the session — or document explicitly thatonCertificatesReceivedis an observer and cannot reject.The first is a behaviour change (a slow listener would delay validation); the second is free. Either is better than the current ambiguity.
Note
We conformed to the current ordering in our port rather than diverging, and documented it as a known upstream behaviour, on the principle that a silent cross-language divergence is worse than a shared quirk.