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 @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...
smime.p7s
Description: S/MIME cryptographic signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
