[openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces
https://github.com/openssl/openssl/pull/1519
Cheers,
Richard
On Tue Aug 30 09:35:42 2016, levitte wrote:
> Good find. I'll fix.
>
> Cheers,
> Richard
>
> On Mon Aug 29 22:06:51 2016, jvea...@gmail.com wrote:
> > I have a Windows machine where Perl is installed in "C:\Program
> > Files\Perl64\bin\perl.exe".
> >
> >
> >
> > When executing "perl Configure VC-WIN32", I get the following error
> >
> >
> >
> > 'C:\Program' is not recognized as an internal or external command,
> >
> > operable program or batch file.
> >
> >
> >
> > I've fixed the problem, by modifying line #2394 in Configure and adding
> > double quotes around $config{perl}.
> >
> >
> >
> > my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\"
> > -o\"Configure\" \"".join("\" \"",@templates)."\" > \"$out.new\"";
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4665
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.
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
Re: [openssl-dev] Is Intel ADX instruction extension supported by the latest OpenSSL?
> I'm looking at how to adopt Intel ADX instruction extension in OpenSSL. Below > man page mentions ADCX/ADOX instructions: > > https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html > > but I can not find ADCX/ADOX related words/expressions from OpenSSL-1.0.2h > source code. I wonder whether OpenSSL already supports ADX. If so, what's the > related code? grep adox crypto/bn/asm/*. As for referred page, do note that there are minimum assembler version requirements. Even though AD[OC]X are not explicitly mentioned, there is minimum requirement even for that, and it's 2.23 for GNU assembler, 2.10 for nasm and 3.3 for clang. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.
> Hm, words fail me. > > Well, that's not entirely true. But *polite* words fail me... :-) > Let me try to understand this... you have always ignored, and still > ignore, the actual LC_CTYPE which tells you the character set in which > the password was provided from the user. > > You *used* to convert it through your horribly misnamed > OPENSSL_asc2uni() function, which actually converts ISO8859-1 to > UTF16BE by simply expanding it and inserting 0x00 between each byte of > the original. So effectively you were "assuming" the input was > ISO8859-1. Unfortunately yes. > Now you assume it's UTF-8, and convert it with OPENSSL_utf8touni(). > (And now what happens when the locale input *isn't* valid UTF-8, > because it's a legacy 8-bit charset? That conversion should fail, > right?) Right. Though more correct formulation probably "is likely to fail" instead of "should fail". > Your latest workaround (from which I started this thread) is addressing > the first problem *purely* for the case of the UTF-8 locale. It checks > for the "we treated UTF-8 as if it were ISO8859-1" case, which is what > leads to the 006e 0061 00c3 00af 0076 0065 example you gave above. Yes. > But you *haven't* actually implemented any workaround for the other > whole set of "we treated locale X as if it were ISO8859-1" bugs > that your original code had. Or the whole set of "we treated local > X as if it were UTF-8" bugs that the new code has. Yes. > 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 :-) :-) :-) 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. I mean the right thing to do is to perform all due conversions to obtain locale-neutral big-endian UTF-16 (though it's not obvious if it's actually desired to bring in dependency on something like iconv into libcrypto), but trouble is that it will more than likely render old data inaccessible. That's why somewhat opportunistic approach is taken in this version, unfortunate as it is. Main goal is that given otherwise unchanged circumstances new version *has to* be able to read old data generated by previous version on the *same* system, irregardless how broken it is. 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). -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces
Good find. I'll fix.
Cheers,
Richard
On Mon Aug 29 22:06:51 2016, jvea...@gmail.com wrote:
> I have a Windows machine where Perl is installed in "C:\Program
> Files\Perl64\bin\perl.exe".
>
>
>
> When executing "perl Configure VC-WIN32", I get the following error
>
>
>
> 'C:\Program' is not recognized as an internal or external command,
>
> operable program or batch file.
>
>
>
> I've fixed the problem, by modifying line #2394 in Configure and adding
> double quotes around $config{perl}.
>
>
>
> my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\"
> -o\"Configure\" \"".join("\" \"",@templates)."\" > \"$out.new\"";
>
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4665
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.
On Mon, 2016-08-29 at 23:01 +0200, Andy Polyakov wrote: > > > > 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. Right. And for the purpose of my example I have moved to eastern Europe and fallen through a time-warp into the 20th century, so I'm using an ISO8859-2 locale. > > 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'. No. My locale is ISO8859-2 so the password "ĂŻ" *is* passed as 'c3 af'. Old OpenSSL will ignore the fact that the locale is ISO8859-2, and perform an ISO8859-1 to UCS16BE conversion using the doubly-misnamed OPENSSL_asc2uni() function. So it'll use '00 c3 00 af'. New OpenSSL will ignore the fact that the locale is ISO8859-2, and perform a UTF-8 to UCS16BE conversion using the only singly renamed OPENSSL_utf82uni() function. So it'll use '00 ef'. You had a bug because you made assumptions about the input data and didn't properly convert from the locale charset to UTF16BE as you should have done. Instead of fixing the bug, you just changed the assumption you made to one that's slightly more likely to be valid in today's world. Leaving the rest of us with *two* buggy behaviours to try to work around. > > > > 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". I'm talking about how other libraries should attempt to read the PKCS#12 files created by OpenSSL. In my code I have the string "ĂŻ" which the user has provided as the password. It doesn't matter what charset it's in, as long as I *know* what charset it's in, and haven't wantonly thrown that information away and started making *assumptions* about how to interpret the stream of bytes. So in order to try to emulate the old OpenSSL bug and read the file, I need to convert to ISO8859-2, then "forget" that it's ISO8859-2 and treat it as ISO8859-1 for the purpose of converting to UTF16BE and trying to decrypt. Which gives me the '00 c3 00 af' as above. And in order to emulate the new OpenSSL bug and read the file, I need to convert to ISO8859-2, then "forget" that it's ISO8859-2 and treat it as UTF-8 for the purpose of converting to UTF16BE and trying to decrypt. Which gives me the '00 ef' that current OpenSSL will use. This latter buggy behaviour hasn't actually been released yet, has it? Is it too late to fix it properly? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
