Awesome, thanks a lot! This is the CI error:
sha256.c:180:2: error: no newline at end of file [-Werror,-Wnewline-eof]

Did you write that sha256 implementation, and if not we need to know where it came from to resolve any potential licensing issues

I am working on the CI errors now. The sha256 implementation is from here: https://github.com/B-Con/crypto-algorithms/blob/master/sha256.c, but I had to change the function names and protoypes to match the ones from openssl.

CI seems to give this error which I am not sure how to go around:

error: ./../docs/libcurl/libcurl-tutorial.3:628: use \fI before curl_slist_free_all(3)
error: ./../docs/libcurl/libcurl-tutorial.3:1216: refering to non-existing man page CURLOPT_HTTPHEADERS.3

It is failing test 1140.

Any suggestions?

The sha256 implementation is from here: https://github.com/B-Con/crypto-algorithms/blob/master/sha256.c, but I had to change the function names and protoypes to match the ones from openssl.

"This code is released into the public domain free of any restrictions. The author requests acknowledgement if the code is used, but does not require it. This code is provided free of any liability and without any quality claims by the author."

Please mention that in the source like "Based on SHA-256 implementation by Brad Conte (brad AT bradconte.com)" and url. Also it is only little endian but we need big endian support as well.

Also does this need to be taken into consideration:

"Note that these are not cryptographically secure implementations. They have no resistence to side-channel attacks and should not be used in contexts that need cryptographically secure implementations."

It is failing test 1140

Should be fixed in 753a5da, can you rebase on master and let the CI run again?

I did the rebase. Hopefully the CI will complete successfully. I have changed the sha implementation and adapted the one from mbedtls (https://github.com/ARMmbed/mbedtls) which should be cryptographically secure. It should support both big and little endian.

Ok. @bagder sha256 is now using an implementation released under apache 2.0 license, I don't know whether that's acceptable or not, it appears to have more requirements than MIT

The Apache 2 license is inconvenient for us because it is considered incompatible with GPLv2, so a curl using a file with that code can't be linked with GPLv2 projects!

What about the openssl implementation? I can look into porting that if it's ok.

The ideal solution would be to use the sha256 implementation that's already in the TLS library that's most likely used as well, which is how the keypinning code does it. OpenSSL is also Apache 2 these days and before that they had another GPL incompatible license so that's not ideal either. The best licenses for us would be MIT or BSD.

Alright. I will try to do it this week.

Here's a BSD licensed sha256.

I added a public domain SHA256 implementation today. It's from libtomcrypt and it was released to public domain. It was easier to port that one.

Awesome, can you look into creating a test case or two as well?

I suppose this code path is triggered automatically based on the header contents, so there's really nothing particular to document? Maybe CURLOPT_HTTPAUTH.3 and CURLOPT_PROXYAUTH.3 at least needs a mention somewhere that we support the RFC7616 style starting with 7.57.0 ?

Alright. Yes.. it is automatic. I'll add some test cases this week and update those 2 docs.

Added some test cases that I thought were relevant.

Finally, good work Florin :) 👍
P.S.

• Others will catch on soon ;)
  Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=472823
  Python: userhash and SHA-256 as in RFC 7616 httplib2/httplib2#23

Thanks a lot @FlorinPetriuc for your hard work on this. Merged now!