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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to