"Theodore Ts'o" <ty...@mit.edu> writes: > However, it should be noted that RFC 8264 also states that code points > which are not defined in whatever version of the Unicode supported by > "the application" shall be disallowed. From Debian's perspective, > though, if we are going to take a position about what version of > Unicode should be supported by "the application(s)" that read and > write /etc/passwd, we *will* need to take a position on what version > of Unicode should be supported, and therefore, what set of characters > will be disallowed.
A possible position may be to treat code points that are the subject of version mismatching to be undefined. This is how IDNA resolved the same problem, and PRECIS inherited this. While I protested about that approach many years ago as libidn maintainer when IDNA2003 was hard-coded to use Unicode 3.2, I think today that the approach is reasonable since Unicode has maintained good stability. We've done a couple of Unicode version bumps in libidn2 and interop with other IDN implementations -- that typically always use some other Unicode version -- is good enough to not cause serious breakage. I would expect the same to be true for PRECIS usernames too. Hostnames are hashed and is subject to string comparisons, just like usernames, so we have some experience to build on here. I would involve cross-distribution discussion about this though. Perhaps the /etc/passwd APIs affect some POSIX specifications, and a non-ASCII extension could be proposed. /Simon
signature.asc
Description: PGP signature
