Commit daf534d from PR #457 breaks the build. This may reintroduce a
clang-analyse warning, but this is the wrong fix for that.
The fix removed a call to mbedtls_ecp_curve_info_from_grp_id() to find
the curve info. This fix adds that back in.
The check is already effectively performed later in the function, but
implicitly, so Clang's analysis fail to notice the functions are in
fact safe. Pulling the check up to the top helps Clang to verify the
behaviour.
Since the buffer is used in a few places, it seems Clang isn't clever
enough to realise that the first byte is never touched. So, even though
the function has a correct null check for ssl->handshake, Clang
complains. Pulling the handshake type out into its own variable is
enough for Clang's analysis to kick in though.
The function appears to be safe, since grow() is called with sensible
arguments in previous functions. Ideally Clang would be clever enough to
realise this. Even if N has size MBEDTLS_MPI_MAX_LIMBS, which will
cause the grow to fail, the affected lines in montmul won't be reached.
Having this sanity check can hardly hurt though.
It is used only by `mbedtls_sha512_process()`, and in case `MBEDTLS_SHA512_PROCESS_ALT` is defined, it still cannot be reused because of `static` declaration.
On x32 systems, pointers are 4-bytes wide and are therefore stored in %e?x
registers (instead of %r?x registers). These registers must be accessed using
"addl" instead of "addq", however the GNU assembler will acccept the generic
"add" instruction and determine the correct opcode based on the registers
passed to it.
The server code parses the client hello extensions even when the
protocol is SSLv3 and this behaviour is non compliant with rfc6101.
Also the server sends extensions in the server hello and omitting
them may prevent interoperability problems.
Commit daf534d from PR #457 breaks the build. This may reintroduce a
clang-analyse warning, but this is the wrong fix for that.
The fix removed a call to mbedtls_ecp_curve_info_from_grp_id() to find
the curve info. This fix adds that back in.
The check is already effectively performed later in the function, but
implicitly, so Clang's analysis fail to notice the functions are in
fact safe. Pulling the check up to the top helps Clang to verify the
behaviour.
Since the buffer is used in a few places, it seems Clang isn't clever
enough to realise that the first byte is never touched. So, even though
the function has a correct null check for ssl->handshake, Clang
complains. Pulling the handshake type out into its own variable is
enough for Clang's analysis to kick in though.
The function appears to be safe, since grow() is called with sensible
arguments in previous functions. Ideally Clang would be clever enough to
realise this. Even if N has size MBEDTLS_MPI_MAX_LIMBS, which will
cause the grow to fail, the affected lines in montmul won't be reached.
Having this sanity check can hardly hurt though.
