Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
Restructed test suite helper and main code to support tests suite helper
functions, changed C++ comments to C-style, and made the generated
source code more navigable.
Added to generate_code.pl:
- support for per test suite helper functions
- description of the structure of the files the script uses to construct
the test suite file
- delimiters through the source code to make the machine generated code
easier to understand
The callback typedefs defined for mbedtls_ssl_set_bio() and
mbedtls_ssl_set_timer_cb() were not used consistently where the callbacks were
referenced in structures or in code.
- basicContraints checks are done during verification
- there is no need to set extensions that are not present to default values,
as the code using the extension will check if it was present using
ext_types. (And default values would not make sense anyway.)
- document why we made that choice
- remove the two TODOs about checking hash and CA
- remove the code that parsed certificate_type: it did nothing except store
the selected type in handshake->cert_type, but that field was never accessed
afterwards. Since handshake_params is now an internal type, we can remove that
field without breaking the ABI.
We don't implement anonymous key exchanges, and we don't intend to, so it can
never happen that an unauthenticated server requests a certificate from us.
After the record contents are decompressed, in_len is no longer
accessed directly, only in_msglen is accessed. in_len is only read by
ssl_parse_record_header() which happens before ssl_prepare_record_contents().
This is also made clear by the fact that in_len is not touched after
decrypting anyway, so if it was accessed after that it would be wrong unless
decryption is used - as this is not the case, it show in_len is not accessed.
Previously it was failing with errors about headers not found, which is
suboptimal in terms of clarity. Now give a clean error with pointer to the
documentation.
Do the checks in the .c files rather than check_config.h as it keeps them
closer to the platform-specific implementations.
The previous documentation was not explicit about what was expected of the
callbacks - the user had to infer that from the descriptions in net.h or
timing.h, and it was not clear what was part of the calling convention and
what was specific to our implementation.
Previously it was failing with errors about headers not found, which is
suboptimal in terms of clarity. Now give a clean error with pointer to the
documentation.
Do the checks in the .c files rather than check_config.h as it keeps them
closer to the platform-specific implementations.
The previous documentation was not explicit about what was expected of the
callbacks - the user had to infer that from the descriptions in net.h or
timing.h, and it was not clear what was part of the calling convention and
what was specific to our implementation.
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.
This re-introduces the apidoc with full config.h, but hopefully with the race
conditions and other issues that the previous implementation had.
Adapt doxygen test script to use that new script, and also check for errors
in addition to warnings while at it.
This partially reverts 1989caf71c (only the changes to Makefile and
CMakeLists, the addition to scripts/config.pl is kept).
Modifying config.h in the apidoc target creates a race condition with
make -j4 all apidoc
where some parts of the library, tests or programs could be built with the
wrong config.h, resulting in all kinds of (semi-random) errors. Recent
versions of CMake mitigate this by adding a .NOTPARALLEL target to the
generated Makefile, but people would still get errors with older CMake
versions that are still in use (eg in RHEL 5), and with plain make.
An additional issue is that, by failing to use cp -p, the apidoc target was
updating the timestamp on config.h, which seems to cause further build issues.
Let's get back to the previous, safe, situation. The improved apidoc building
will be resurrected in a script in the next commit.
fixes#390fixes#391
Apparently travis has an old version of doxygen that doesn't know all tags in
our config. That's not something we care about, we only want to know about
warnings in our doxygen content
On my machine, that reduces running time from about 30 minutes to less than 10
minutes, while maintaining a good probability of catching the most likely
issues in practice.
