Add SASLprep. Code generated & tested with RFC3454 #64
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RFC-4422 recommends that mechanisms SHOULD prepare simple usernames and passwords with SASLprep. And SASLprep is required by the `SCRAM-*` mechanisms, which will be added in a future PR. SASLprep is also recommended for the `PLAIN` SASL mechanism and for the `ACL` IMAP extension but—in both cases—string preparation is done by the *server*, at its own discretion. SASLprep has been officially obsoleted by PRECIS. I don't believe any IMAP RFCs have allowed replacing SASLprep with PRECIS yet. In contrast, RFC-7622 updates XMPP to require PRECIS. (See RFC-8265 for more info on PRECIS, and Section 6 for migration considerations.) Rather than create a fully generic StringPrep superclass or function, the SASLprep profile is optimized. Just enough of the generic StringPrep algorithm has been implemented to provide more detailed errors for prohibited strings. Future PRs can expand it as needed, to implement other profiles. In particular, the `trace` StringPrep profile is a requirement for clients using the `ANONYMOUS` mechanism. Many other StringPrep implementations store the tables as an array of ranges and loop over every character in the input. But using Regexp is simpler and much faster, especially where the tables closely match Unicode character classes (benchmarks are included). Some StringPrep tables use Regexps that are generated from the RFC-3454 appendices. Manually written regular expressions are used in cases where there is a close match between Unicode character classes and the SASLprep tables. All regexps are tested against the RFC tables with every valid codepoint, to verify they aren't broken if their character classes are changed by new versions of Unicode. Additionally: * Added `rake rfcs` to download many IMAP-related RFCs, for convenience. * The new code is namespaced under `Net::IMAP::SASL`. We could move the authenticators there too. If SASL funcionality is ever extracted to another gem, we can use: `Net::IMAP::SASL = Net::SASL` for backward compatibility.
|
|
37 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
RFC-4422 recommends that mechanisms SHOULD prepare simple usernames and passwords with SASLprep. And SASLprep is required by the
SCRAM-*mechanisms, which will be added in a future PR.SASLprep is also recommended for the
PLAINSASL mechanism and for theACLIMAP extension but—in both cases—string preparation is done by the server, at its own discretion.SASLprep has been officially obsoleted by PRECIS. I don't believe any IMAP RFCs have allowed replacing SASLprep with PRECIS yet. In contrast, RFC-7622 updates XMPP to require PRECIS. (See RFC-8265 for more info on PRECIS, and Section 6 for migration considerations.)
Rather than create a fully generic StringPrep superclass or function, the SASLprep profile is optimized. Just enough of the generic StringPrep algorithm has been implemented to provide more detailed errors for prohibited strings. Future PRs can expand it as needed, to implement other profiles. In particular, the
traceStringPrep profile is a requirement for clients using theANONYMOUSmechanism.Many other StringPrep implementations store the tables as an array of ranges and loop over every character in the input. But using Regexp is simpler and much faster, especially where the tables closely match Unicode character classes (benchmarks are included). Some StringPrep tables use Regexps that are generated from the RFC-3454 appendices. Manually written regular expressions are used in cases where there is a close match between Unicode character classes and the SASLprep tables. All regexps are tested against the RFC tables with every valid codepoint, to verify they aren't broken if their character classes are changed by new versions of Unicode.
Additionally:
rake rfcsto download many IMAP-related RFCs, for convenience.Net::IMAP::SASL. We could move the authenticators there too. If SASL funcionality is ever extracted to another gem, we can use:Net::IMAP::SASL = Net::SASLfor backward compatibility.