On Tue, Dec 13, 2016 at 2:44 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > SASLPrep is defined here: > https://tools.ietf.org/html/rfc4013 > And stringprep is here: > https://tools.ietf.org/html/rfc3454 > So that's roughly applying a conversion from the mapping table, taking > into account prohibited, bi-directional, mapping characters, etc. The > spec says that the password should be in unicode. But we cannot be > sure of that, right? Those mapping tables should be likely a separated > thing.. (perl has Unicode::Stringprep::Mapping for example).
OK. I have look at that and I have bumped into libidn, that offers a couple of APIs that could be used directly for this purpose. Particularly, what has caught my eyes is stringprep_profile(): https://www.gnu.org/software/libidn/manual/html_node/Stringprep-Functions.html res = stringprep_profile (input, output, "SASLprep", STRINGPREP_NO_UNASSIGNED); libidn can be installed on Windows, and I have found packages for cygwin, mingw, linux, freebsd and macos via brew. In the case where libidn is not installed, I think that the safest path would be to check if the input string has any high bits set (0x80) and bail out because that would mean that it is a UTF-8 string that we cannot change. Any thoughts about using libidn? Also, after discussion with Heikki, here are the things that we need to do: 1) In libpq, we need to check if the string is valid utf-8. If that's valid utf-8, apply SASLprep. if not, copy the string as-is. We could error as well in this case... Perhaps a WARNING could be more adapted, that's the most tricky case, and if the client does not use utf-8 that may lead to unexpected behavior. 2) In server, when the password verifier is created. If client_encoding is utf-8, but not server_encoding, convert the password to utf-8 and build the verifier after applying SASLprep. In the case where the binaries are *not* built with libidn, I think that we had better reject valid UTF-8 string directly and just allow ASCII? SASLprep is a no-op on ASCII characters. Thoughts about this approach? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
