Viktor Dukhovni <[email protected]> skrev: (7 juni 2018 21:16:53 CEST) >On Thu, Jun 07, 2018 at 09:01:15PM +0200, Richard Levitte wrote: > >> We don't have to answer the question "how high" now. I'm fully >> prepared to have the use of iconv limited to platforms where we know >> it's available (for example, we - or well, *I* - know that VMS has >the >> iconv API in the C RTL, not even any need to link with any extra >> library... and we *know* it's available in glibc since version >> 2.something). I'm fully prepared to have to deal with people saying >> "hey, we have that too!" and having to edit config targets as we go. >> I do not expect any support of iconv to cover more than what we can >> test or get patches for, as with anything else. > >There's also apparently some variation in the iconv API function >prototypes (possibly "const char **" vs. "char **"). So some >platform-dependent casting may be required... > >My peers suggest that this late in the release cycle, we leave the >responsibility of ensuring UTF-8 input to the user. We could >describe work-arounds in documentation. Personally, if this is >off by default, and requires a new option to enable, and is just >in openssl(1) and not libcrypto, I'm disinclined to say "no" until >I see a PR (with documentation) that we can decide to leave for >post 1.1.1 or adopt.
Please review doc/man7/passphrase-encoding.pod My main concern is that currently, openssl pkcs12 may create broken pkcs12 files (because it misinterprets the pass phrase when constructing a BMPString), and doesn't notify the user at all (doesn't even check). Cheers Richard -- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet. _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
