On Tue, 2016-08-30 at 12:38 +0200, Andy Polyakov wrote: > > So for other applications to try to read OpenSSL's PKCs#12 files, what > > we need to do is first convert the sane Unicode rendition of the > > password into the native locale charset (e.g. Windows-1252), then take > > that bytestream and *pretend* it's ISO8859-1, and convert to UTF-16BE > > to check the MAC. Then if that fails, take the same Windows-1252 > > bytestream and *pretend* it's UTF-8, and convert *that* to UTF-16BE to > > see if it works. > > Are you sure you want to know? I mean you already said "I wish I hadn't > ask", and now you are bringing Windows into conversation :-) :-) :-)
I concede, I am a masochist. :) > Yes, it's as bad as you can possibly imagine, and trouble is that there > is no "right thing" to do *if* you formulate "keep old data accessible" > as goal. Yeah, if you want to be able to create PKCS#12 files that'll work (in the same locale) with older versions of OpenSSL, you're kind of stuck. I can live with that historical accident, and the workaround of "convert to the locale charset, then pretend that's ISO8859-1 and try again". I can even live with the fact that, for the reasons you've stated, OpenSSL *still* produces files which need that workaround. But I *really* wish you hadn't added *another* bug, and required another workaround.... > At the same time a way to access and generate > specification-compliant data is provided (on *ix it takes *an* UTF8 > locale, which is default in absolute majority of cases bu now, and on > Windows it's an *opt-in* environment variable for the time being). ... so instead of doing the UTF-8 thing whenever the incoming bytestream happens to be interpretable as valid UTF-8, why not do it only if LC_CTYPE actually *is* UTF-8? So my (admittedly contrived and unlikely) example of "ĂŻ" in an ISO8859-2 locale would only continue to do the *old* wrong thing, and not a *new* wrong thing that needs an additional workaround :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev