On 11/20/15 10:20, Dmitry Belyavsky wrote: > Dear Andy, > > On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov <ap...@openssl.org > <mailto:ap...@openssl.org>> wrote: > > > ... And on Windows it's even worse. As it stands now > > even passing non-ASCII strings as command-line argument [and presumably > > at prompt] is not an option. > > This is not entirely true. Whether or not one can pass non-ASCII strings > as command-line argument is language-specific. Or rather code > page-specific in Windowish. With Asian languages you're really out of > luck, while smaller alphabets can work out (but not mixed) if system > locale matches expectations. > > > I understand that there should be problems with Windows.
To eliminate possibility of misunderstanding. Claim is not limited to problems with Windows, but that OpenSSL handles non-ASCII characters in apparently non-interoperable way. On all systems. I referred to Windows as complicating factor in the problem, not whole/separate problem. > So the test PKCS12 object was created using Windows using a > GOST-providing CSP. > > I do not know whether the authors of the CSP have implemented their own > mechanism of transforming the password or used any provided by the > Windows system default. What are chances that they too used same formally incorrect approach? > But in fact the openssl being built without defining the PBE_UNICODE > macros was able to parse the test PKCS12. Right. Doing otherwise will put burden of big-endian UTF-16 conversion on caller and chances that caller gets it right are low. > Thank you! ??? So suggestion is leave it as it is? Well, given the presented evidence doing the right thing should break things for you. But does it mean that one can/should be excused from getting things right? _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
