SecretBuffer must support a password normalization routine like SASLprep and/or PRECIS.

[sambitdash]

SASLprep can be closely assumed as a :NFKC Unicode normalization with some exclusion of unsupported characters.

There are two challenges wrt Julia here.

1. All unicode methods take AbstractString as input defeating the purpose of SecretBuffer
2. SecretBuffer itself does not support the manipulation routines.

[KristofferC]

What purpose do you think SecretBuffer has?

[sambitdash]

Is it not supposed to hold the password or other secrets temporarily? When input from a TTY has Unicode characters, how will you manipulate the input? The moment you convert the data to String for Unicode normalization, the purpose of using SecretBuffer is lost. Do you want to restrict the passwords to be within the ASCII range only?

[sambitdash]

It may be OK to implement SASLprep in the getpass routine and pass the processed output to a SecretBuffer.

[StefanKarpinski]

The latest RFC along those lines seems to be https://tools.ietf.org/html/rfc8265. I guess the idea is that a username or a password could appear not to match because of inconsistencies in the input method that the user has no control over or visibility into. So the Unicode sequence should be normalized to avoid that problem. The reason the password can't just be normalized by a string function is that then copies are made, allowing the secret to escape.

[sambitdash]

Since, SecretBuffer has an IO interface, a character stream based method can be developed for SASLprep or PRECIS as well. It may also require the Unicode.normalize methods to have a character stream interface along with a string interface or any similar approach.