Auths: in plaintext authenticator, fix parsing of consecutive circuflex. Bug 2687

[exim.git] / doc / doc-docbook / spec.xfpt

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index bb053ed783de692d3c6e9551ea61c8e051eb05b9..15b03eabbe43909ca04e7feb8dc99b6164ce7b05 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -27824,7 +27824,14 @@ fixed_plain:
   client_send = ^username^mysecret
 .endd
 The lack of colons means that the entire text is sent with the AUTH
-command, with the circumflex characters converted to NULs. A similar example
+command, with the circumflex characters converted to NULs.
+.new
+Note that due to the ambiguity of parsing three consectutive circumflex characters
+there is no way to provide a password having a leading circumflex.
+.wen
+
+
+A similar example
 that uses the LOGIN mechanism is:
 .code
 fixed_login:
@@ -28181,6 +28188,10 @@ supplied by the server.
 .option server_channelbinding gsasl boolean false
 Do not set this true and rely on the properties
 without consulting a cryptographic engineer.
+. Unsure what that's about.  It might be the "Triple Handshake"
+. vulnerability; cf. https://www.mitls.org/pages/attacks/3SHAKE
+. If so, we're ok, requiring Extended Master Secret if TLS
+. Session Resumption was used.
 
 Some authentication mechanisms are able to use external context at both ends
 of the session to bind the authentication to that context, and fail the