Initial mbedTLS 3.0.0 support#7428
Conversation
|
It seems this breaks the build of the older mbedtls version? |
|
ok sha256.c has an inconsistent |
danielgustafsson
left a comment
danielgustafsson
left a comment
There was a problem hiding this comment.
I would not be comfortable in merging this unless we can an mbedTLS 3.0 job in the CI, are there stable packages around to make that happen?
lib/md4.c
Outdated
There was a problem hiding this comment.
Since the change that altered the header includes was introduced in 3, the check should be reversed and include the new file iff we are compiling against 3 and not the other way around. Nitpick to some extent, but it will improve readability.
Also, why doesn't this (and the remaining changes) use MBEDTLS_VERSION_NUMBER as the rest if the code does?
lib/vtls/mbedtls.c
Outdated
There was a problem hiding this comment.
This might be a dumb question, but I don't know mbedtls at all. Does this mean that the fields we need are now private but were public in the past, or have they always been private?
There was a problem hiding this comment.
quote from mbedtls developer:
Fields in structures are now private by default. We're aware that we may have been overeager in some places, and we're likely to make a few fields public again in 3.x minor releases, or to add new accessor functions.
#7376 (comment)
There was a problem hiding this comment.
That sounds really scary, the fact that a member is private means that it can go away or radically change at any time. Relying on that not happening seems pretty terrible, but that's again not the fault of this patch.
lib/vtls/mbedtls.c
Outdated
There was a problem hiding this comment.
This makes the code too hard to parse. Since the TLS support is so vastly different, I think we should provide two different implementations of mbedtls_version_from_curl entirely and do the version preprocessing around those rather than pick this one apart.
lib/vtls/mbedtls.c
Outdated
There was a problem hiding this comment.
The fact that we now use the same function name in 3 that we used in 2.0.x which was deprecated in favour of _ret in 2.x needs a pretty big comment explaining how that mess is strung together.
Also, while not a fault of this PR, blimey thats ugly..
I presume we can always get it from git and build our own version. But yes, I too would like to have that in the CI when we merge v3 support. |
|
I made the requested changes now by the way except i'm not a good documentation writter for "a pretty big comment explaining how that mess is strung together"... |
lib/sha256.c
Outdated
There was a problem hiding this comment.
Wouldn't the code be easier if this code block instead was made like?
#if(MBEDTLS_VERSION_NUMBER >= 0x02070000) && \
(MBEDTLS_VERSION_NUMBER < 0x03000000)
#define HAS_MBEDTLS_RESULT_CODE_BASED_FUNCTIONS
#endif
That's fine, we're all in this together and can collaborate. I would recommend adding a |
|
done |
jsoref
left a comment
jsoref
left a comment
There was a problem hiding this comment.
Some drive-by-thoughts. Feel free to ignore.
I'd be happy to offer comments on the TODO text, but it doesn't make enough sense to me to comment at this time.
lib/md4.c
Outdated
There was a problem hiding this comment.
This blank line seems odd... (compare lin 39/40 of lib/md5.c below)
lib/vtls/mbedtls.c
Outdated
There was a problem hiding this comment.
In general, wouldn't the preference be to put this before the MBEDTLS_VERSION_NUMBER < 0x02070000?
lib/md4.c
Outdated
There was a problem hiding this comment.
note to self: this is an #ifdef
lib/sha256.c
Outdated
There was a problem hiding this comment.
Is there a style guide for #if !defined... vs #ifndef?
https://github.com/curl/curl/search?q=ifndef it looks like both flavors are used...
offhand, it looks like #if !defined... tends to be used with a boolean operator for when one is performing multiple checks concurrently.
https://github.com/curl/curl/search?p=2&q=%22%23if+%21defined%22
(Yes, I understand this is preexisting code.)
There was a problem hiding this comment.
Is there a style guide for #if !defined... vs #ifndef?
We prefer #ifdef and #ifndef if you only check a single define. If you check more than one, then #if needs to be used.
|
Can you please squash the commits, rebase and force-push to make this easier to review? Then I figure we only need a CI job added for mbedTLS. I might take a stab at that. |
|
Done |
|
Any chance of getting this merged soon? This fixes #7385, and looks about how we solved most of the problems before we ran out of time. |
|
Once we have a CI build setup that verifies this build I'll be ready to merge. |
|
Thanks! |
5 participants
Tested in android and windows and works
Notice: I'm not sure if I've done the tls handling correctly as newest mbedtls 3 drops tls 1.1, 1.2 supports, comments welcome....
And I've not heard from mbedtls developer about prettier access to private member of some structures, so I have to use MBEDTLS_PRIVATE macros...
see #7376 (comment)