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 17:06:58 +0100
On Thu, 2022-07-21 at 17:40 +0200, Daniel Stenberg wrote:
> On Thu, 21 Jul 2022, David Woodhouse wrote:
>
> > > 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'?
>
> Yeah, I suppose you could say that it *should* care about character sets in
> some of those cases but it doesn't and it never did. It presumes the user
> passes on exactly what it wants to pass on.
For the data to be passed over the wire, that's a tolerable assumption
as long as we *also* pass a suitable Content-Type: header with a
charset identifying the charset of the user's locale in which the data
are presumed to be encoded.
Which we don't.
$ LANG=cs_CZ.ISO8859-2 curl http://twosheds.infradead.org/cgi-bin/foo.cgi -d naïve=true -v
* Trying 2001:8b0:10b:1:21d:7dff:fe04:dbe2:80...
* TCP_NODELAY set
* Connected to twosheds.infradead.org (2001:8b0:10b:1:21d:7dff:fe04:dbe2) port 80 (#0)
> POST /cgi-bin/foo.cgi HTTP/1.1
> Host: twosheds.infradead.org
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 11
> Content-Type: application/x-www-form-urlencoded
But I was steering clear of that one, as it's at least slightly
subjective. On the other hand, when we're given a password on the
command line (in the locale charset) and we *fail* to convert that
properly to a UCS2 BMPString to open a certificate file, that's just
buggy. We don't get to hide behind "user should have passed on exactly
what it wants to pass on" in that case. That's the example I used.
> > 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 :(
>
> Correct. Nobody taught it how to do that.
>
The problem there is that all crypto libraries hate users, and hate
programmers. And it takes literally *thousands* of lines of code just
to conform to the basic "common sense" usability guidelines that I've
written up at
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
I'm half tempted to split that part out of OpenConnect, which solves it
at least for OpenSSL and GnuTLS as an SSL client, and make it available
as a library for other software to use. You then get full support for
PKCS#11, TPMv1.2, TPMv2.0, all sensible file types, and some of the
system stores like Windows and Mac OS keychain, all mostly for free.
If there were someone who actively wanted to *use* that, and perhaps
make something like curl use it, then it might motivate me to actually
work on splitting it out into a standalone library...
Received on 2022-07-21
Date: Thu, 21 Jul 2022 17:06:58 +0100
On Thu, 2022-07-21 at 17:40 +0200, Daniel Stenberg wrote:
> On Thu, 21 Jul 2022, David Woodhouse wrote:
>
> > > 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'?
>
> Yeah, I suppose you could say that it *should* care about character sets in
> some of those cases but it doesn't and it never did. It presumes the user
> passes on exactly what it wants to pass on.
For the data to be passed over the wire, that's a tolerable assumption
as long as we *also* pass a suitable Content-Type: header with a
charset identifying the charset of the user's locale in which the data
are presumed to be encoded.
Which we don't.
$ LANG=cs_CZ.ISO8859-2 curl http://twosheds.infradead.org/cgi-bin/foo.cgi -d naïve=true -v
* Trying 2001:8b0:10b:1:21d:7dff:fe04:dbe2:80...
* TCP_NODELAY set
* Connected to twosheds.infradead.org (2001:8b0:10b:1:21d:7dff:fe04:dbe2) port 80 (#0)
> POST /cgi-bin/foo.cgi HTTP/1.1
> Host: twosheds.infradead.org
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 11
> Content-Type: application/x-www-form-urlencoded
But I was steering clear of that one, as it's at least slightly
subjective. On the other hand, when we're given a password on the
command line (in the locale charset) and we *fail* to convert that
properly to a UCS2 BMPString to open a certificate file, that's just
buggy. We don't get to hide behind "user should have passed on exactly
what it wants to pass on" in that case. That's the example I used.
> > 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 :(
>
> Correct. Nobody taught it how to do that.
>
The problem there is that all crypto libraries hate users, and hate
programmers. And it takes literally *thousands* of lines of code just
to conform to the basic "common sense" usability guidelines that I've
written up at
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
I'm half tempted to split that part out of OpenConnect, which solves it
at least for OpenSSL and GnuTLS as an SSL client, and make it available
as a library for other software to use. You then get full support for
PKCS#11, TPMv1.2, TPMv2.0, all sensible file types, and some of the
system stores like Windows and Mac OS keychain, all mostly for free.
If there were someone who actively wanted to *use* that, and perhaps
make something like curl use it, then it might motivate me to actually
work on splitting it out into a standalone library...
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pkcs7-signature attachment: smime.p7s