On Wed, 2022-07-20 at 22:46 +0200, Daniel Stenberg wrote: > On Wed, 20 Jul 2022, David Woodhouse via curl-library wrote: > > > Which doesn't negate the fact that we still need to care about legacy > > character sets unless we just want to be buggy for all non-ASCII content, > > surely? > > I'm not following. In what aspect does curl care about non-ASCII content or > character sets at all?
Passwords and passphrases, input on the command line or '-d @postdata'? That PKCS#12 certificate file with a passphrase of 'ĂŻ', for example, is surely going to go horribly wrong if you don't know which character set is used when the password is handed to you as a set of bytes. You can try it, in various locales... https://gitlab.com/openconnect/openconnect/-/blob/master/tests/certs/user-key-nonascii-password.p12 As I said, the password is: U+0102 LATIN CAPITAL LETTER A WITH BREVE U+017B LATIN CAPITAL LETTER Z WITH DOT ABOVE https://gitlab.com/openconnect/openconnect/-/blob/master/tests/pass-ISO8859-2 contains the bytes 0xc3 0xaf 0x0a https://gitlab.com/openconnect/openconnect/-/blob/master/tests/pass-UTF-8 contains the bytes 0xc4 0x82 0xc5 0xbb 0x0a (both include trailing newlines). These commands work, and are part of my test suite: ~/git/openconnect/tests/certs$ LANG=cs_CZ.ISO8859-2 openconnect -c user-key-nonascii-password.p12 --key-password `cat ../pass-ISO8859-2` www.facebook.com ~/git/openconnect/tests/certs$ LANG=en_GB.UTF-8 openconnect -c user-key-nonascii-password.p12 --key-password `cat ../pass-UTF-8` www.facebook.com AFAICT it works with curl in a UTF-8 environment but nothing else. This one works: ~/git/openconnect/tests/certs$ LANG=en_GB.UTF-8 curl -E user-key-nonascii-password.p12:`cat ../pass-UTF-8` --cert-type P12 https://www.facebook.com/ But this doesn't: ~/git/openconnect/tests/certs$ LANG=cs_CZ.ISO8859-2 curl -E user-key-nonascii-password.p12:`cat ../pass-ISO8859-2` --cert-type P12 https://www.facebook.com/ curl: (58) could not parse PKCS12 file, check password, OpenSSL error error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure And ew, I still have to *tell* curl that the file it is looking at is a PKCS#12 file, because it doesn't work that out for itself :( As a general rule, *anything* you get from local files or command line or terminal input will be in a *defined* character set, and software is responsible for either *labelling* it correctly when sending it on, or converting converting to the expected charset if labelling isn't possible (for example when outputting to the terminal).
smime.p7s
Description: S/MIME cryptographic signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
