> So let's try a better example. The password is "ĂŻ" (U+0102 U+017b), > and the locale (not that it *should* matter) is ISO8859-2.
When it comes to locale in *this* case you should rather wonder what does your terminal emulator program do and how does it interact with your shell. Because these two are responsible for composing the string that OPENSSL_[asc|utf8]2uni gets. > The correct rendition is 01 02 01 7b. Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as argument or console input under an UTF-8 locale. Otherwise it would have been passed as 'c3 af'. > The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be > to *convert* to ISO8859-2 (giving c3 af). No, no conversion from UTF-8 to ISO8859-x or any other conversion was *ever* performed. Nor is it performed now. It was and still is all about how string is composed by *somebody else*. That's why I said that "we assume that you don't change locale when you upgrade OpenSSL". > Then to interpret those bytes > as ISO8859-1 (in which they would mean "ï") and convert *that* to > UTF16LE to give 00 c3 00 af Previously OpenSSL would convert 'c4 82 c5 bb' to '00 c4 00 82 00 c5 00 bb'. Now it converts it to '01 02 01 7b', but attempts even '00 c4 00 82 00 c5 00 bb' for "old times sake". And for 'c3 af' question is if it's valid UTF-8 encoding. If it is (it is in this example), then it would attempt '00 ef' (in this example) and then '00 c3 00 af', and if not, then it would go straight to '00 c3 00 af'. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev