Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Is EBCDIC support gone?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: David Woodhouse via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 21 Jul 2022 09:54:05 +0100
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 _at_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).
Received on 2022-07-21
Date: Thu, 21 Jul 2022 09:54:05 +0100
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 _at_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).
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pkcs7-signature attachment: smime.p7s