We're including psa/crypto_values.h, which defines the necessary error
codes. Remove redundant definitions, which hurt because they need to be
styled in exactly the same way (same presence/absence of spaces between
tokens).
This completes the fix of https://github.com/Mbed-TLS/mbedtls/issues/6875.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Reject "weird" characters in text files, especially control characters that
might be escape sequences or that might cause other text to appear garbled
(as in https://trojansource.codes/).
Also reject byte sequences that aren't valid UTF-8.
Accept only ASCII (except most control characters), letters, some non-ASCII
punctuation and some mathematical and technical symbols. This covers
everything that's currently present in Mbed TLS ( §áèéëñóöüłŽ–—’“”…≥).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These variables were both uses to select the default version of OpenSSL
to use for tests:
- when running compat.sh or ssl-opt.sh directly, OPENSSL_CMD was used;
- when running all.sh, OPENSSL was used.
This caused surprising situations if you had one but not the other set
in your environment. For example I used to have OPENSSL_CMD set but not
OPENSSL, so ssl-opt.sh was failing in some all.sh components but passing
when I ran it manually in the same configuration and build, a rather
unpleasant experience.
The natural name would be OPENSSL, and that's what set in the Docker
images used by the CI. However back in the 1.3.x days, that name was
already used in library/Makefile, so it was preferable to pick a
different one, hence OPENSSL_CMD. However the build system has not been
using this name since at least Mbed TLS 2.0.0, so it's now free for use
again (as demonstrated by the fact that it's been set in the CI without
causing any trouble).
So, unify things and use OPENSSL everywhere. Just leave an error message
for the benefit of developers which might have OPENSSL_CMD, not OPENSSL,
set in their environment from the old days.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Modify generate_errors.pl such that it can now handle
opening files where the file path includes a directory
name containing spaces.
Raised in issue #6879. Fix provided by
@tom-cosgrove-arm in aforementioned issue.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
Two macros are also defined in headers in the PSA Compliance test suite, so
the test suite would fail to build if we changed the definitions. Preserve
those definitions. Technically this is a bug in the test suite, since having
extra spaces (or even a completely different constant expression with the
same value) would still be compliant. Bug reported as
https://github.com/ARM-software/psa-arch-tests/issues/337
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
For PSA error code definitions, the specific expansion is mandated by the
PSA Status code specification and the PSA Crypto API specification. In
particular, there must not be a space between (psa_status_t) and the
numerical value (whereas K&R would put a space).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move the *INDENT-ON* annotation to the end of the file so that
uncrustify does not restyle the later sections (since it introduces a
risk of future problems).
Signed-off-by: David Horstmann <david.horstmann@arm.com>
mbedtls_test_psa_setup_key_derivation_wrap() returns 1 for success, 0
for error, so the test here was wrong.
This is just a hotfix in order to avoid a testing gap. Larger issues not
addressed here:
- I don't think we should just exit and mark the test as passed; if
we're not doing the actual testing this should be marked as SKIP.
- Returning 1 for success and 0 for failure is a violation of our
documented coding guidelines. We're also supposed to test with == 0 or
!= 0. Having consistent conventions is supposed to help avoid errors
like this.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The inline assembly defined in bn_mul.h confuses code style parsing,
causing code style correction to fail. Disable code style correction for
the whole section gated by "#if defined(MBEDTLS_HAVE_ASM)" to prevent
this.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The following code:
#ifndef asm
#define asm __asm
#endif
causes Uncrustify to stop correcting the rest of the file. This may be
due to parsing the "asm" keyword in the definition.
Work around this by wrapping the idiom in an *INDENT-OFF* comment
wherever it appears.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The script was parsing the output from `make lcov` to extract numbers and
calculate percentages. But everything including the percentages is already
present in the output of `make lcov`, just with a slightly different
presentation. So replace all this by a simple extraction of the relevant
lines from the output of `make lcov`.
This is more robust than the previous code, which relied on `tail -n4` to
extract relevant lines, which broke when `make lcov` started to emit one
extra line at the end.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Ideally the result of the generator would conform to the code style, but
this would be difficult, especially with respect to the placement of line
breaks in long logical lines. So, to avoid surprises when checking the style
of generated files (which happens in releases and in long-time support
branches), systematically skip generated files.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Allow check_names.py to detect declarations of the form:
enum some_enum_name {
This pattern has only just appeared due to code style correction, which
explains why the issue was not previously noticed.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
