send_sasl_plain() is hardcoded at backend/irc.rs:437; PLAIN is the only mechanism offered. No EXTERNAL (CertFP), no SCRAM-SHA-256, no ECDSA-NIST256P-CHALLENGE.
EXTERNAL matters most: it is how you authenticate with a client certificate instead of sending a password at all, and it is widely supported (Libera, OFTC, Rizon).
Done looks like: read the mechanism list from the CAP response and pick the strongest configured one, with EXTERNAL driven by a per-account certificate path.
`send_sasl_plain()` is hardcoded at `backend/irc.rs:437`; PLAIN is the only mechanism offered. No EXTERNAL (CertFP), no SCRAM-SHA-256, no ECDSA-NIST256P-CHALLENGE.
EXTERNAL matters most: it is how you authenticate with a client certificate instead of sending a password at all, and it is widely supported (Libera, OFTC, Rizon).
**Done looks like:** read the mechanism list from the CAP response and pick the strongest configured one, with EXTERNAL driven by a per-account certificate path.
EXTERNAL authenticates with the TLS client certificate already on the connection, so no password is sent at all. The certificate is set on the connection rather than in a message, because that is what the server actually checks.
SCRAM-SHA-256 proves knowledge of the password without sending it, and proves the server knew it too. That second half is verified rather than skipped — a server that cannot produce the right signature is refused outright with a message saying so, because the password was never sent, so a failure there is not a wrong login. It is a server that cannot show it is the one you registered with.
HMAC-SHA-256 is implemented in backend/irc_sasl.rs rather than pulled in: this crate's hmac is 0.13, which pairs with digest 0.11 hashes, while its sha2 is 0.10, which needs 0.12. Twenty lines checked against RFC 4231's vectors beat moving a dependency the rest of the daemon is built on. The SCRAM exchange is checked end to end against RFC 7677's worked example — client proof and server signature both — plus nonce-extension, iteration-count and server-refusal cases.
PLAIN stays the default, which is the part worth arguing. SCRAM is barely deployed on IRC — Ergo has it, Libera and Rizon do not — and the spec only recommends that a server answer an unknown mechanism with the list of ones it has. Leading with SCRAM would have broken SASL outright on the networks you actually use, on servers that decline to say why. So SCRAM is there for whoever names it, a configured certificate implies EXTERNAL, and a server that does answer with 908 gets its choice honoured automatically without a reconnect.
Not implemented: ECDSA-NIST256P-CHALLENGE. Libera offers it, but it is a nonstandard mechanism needing secp256k1 signing, and EXTERNAL covers the same ground with a certificate.
Finished — https://git.salastil.com/Salastil/nobilis/commit/2f37c47 and https://git.salastil.com/Salastil/moho/commit/f476679
**EXTERNAL** authenticates with the TLS client certificate already on the connection, so no password is sent at all. The certificate is set on the connection rather than in a message, because that is what the server actually checks.
**SCRAM-SHA-256** proves knowledge of the password without sending it, and proves the server knew it too. That second half is verified rather than skipped — a server that cannot produce the right signature is refused outright with a message saying so, because the password was never sent, so a failure there is not a wrong login. It is a server that cannot show it is the one you registered with.
HMAC-SHA-256 is implemented in `backend/irc_sasl.rs` rather than pulled in: this crate's `hmac` is 0.13, which pairs with digest 0.11 hashes, while its `sha2` is 0.10, which needs 0.12. Twenty lines checked against RFC 4231's vectors beat moving a dependency the rest of the daemon is built on. The SCRAM exchange is checked end to end against RFC 7677's worked example — client proof and server signature both — plus nonce-extension, iteration-count and server-refusal cases.
**PLAIN stays the default**, which is the part worth arguing. SCRAM is barely deployed on IRC — Ergo has it, Libera and Rizon do not — and the spec only *recommends* that a server answer an unknown mechanism with the list of ones it has. Leading with SCRAM would have broken SASL outright on the networks you actually use, on servers that decline to say why. So SCRAM is there for whoever names it, a configured certificate implies EXTERNAL, and a server that does answer with 908 gets its choice honoured automatically without a reconnect.
Not implemented: ECDSA-NIST256P-CHALLENGE. Libera offers it, but it is a nonstandard mechanism needing secp256k1 signing, and EXTERNAL covers the same ground with a certificate.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
send_sasl_plain()is hardcoded atbackend/irc.rs:437; PLAIN is the only mechanism offered. No EXTERNAL (CertFP), no SCRAM-SHA-256, no ECDSA-NIST256P-CHALLENGE.EXTERNAL matters most: it is how you authenticate with a client certificate instead of sending a password at all, and it is widely supported (Libera, OFTC, Rizon).
Done looks like: read the mechanism list from the CAP response and pick the strongest configured one, with EXTERNAL driven by a per-account certificate path.
Finished — https://git.salastil.com/Salastil/nobilis/commit/2f37c47 and https://git.salastil.com/Salastil/moho/commit/f476679
EXTERNAL authenticates with the TLS client certificate already on the connection, so no password is sent at all. The certificate is set on the connection rather than in a message, because that is what the server actually checks.
SCRAM-SHA-256 proves knowledge of the password without sending it, and proves the server knew it too. That second half is verified rather than skipped — a server that cannot produce the right signature is refused outright with a message saying so, because the password was never sent, so a failure there is not a wrong login. It is a server that cannot show it is the one you registered with.
HMAC-SHA-256 is implemented in
backend/irc_sasl.rsrather than pulled in: this crate'shmacis 0.13, which pairs with digest 0.11 hashes, while itssha2is 0.10, which needs 0.12. Twenty lines checked against RFC 4231's vectors beat moving a dependency the rest of the daemon is built on. The SCRAM exchange is checked end to end against RFC 7677's worked example — client proof and server signature both — plus nonce-extension, iteration-count and server-refusal cases.PLAIN stays the default, which is the part worth arguing. SCRAM is barely deployed on IRC — Ergo has it, Libera and Rizon do not — and the spec only recommends that a server answer an unknown mechanism with the list of ones it has. Leading with SCRAM would have broken SASL outright on the networks you actually use, on servers that decline to say why. So SCRAM is there for whoever names it, a configured certificate implies EXTERNAL, and a server that does answer with 908 gets its choice honoured automatically without a reconnect.
Not implemented: ECDSA-NIST256P-CHALLENGE. Libera offers it, but it is a nonstandard mechanism needing secp256k1 signing, and EXTERNAL covers the same ground with a certificate.