The new file programs/demo_common.sh contains initialization code,
utility functions and cleanup code meant to be used by all demo
scripts written in sh.
Initial features:
* msg: Display a message.
* run, run_bad: Run a command, visibly.
* $root_dir, $programs_dir: location of the mbedtls source tree.
* $files_to_clean: files that are cleaned up on exit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Allow demo scripts to be run from the build directory for out-of-tree
builds.
If the executable is not found in the source tree then search in the
current directory in case the script is being run from a build
directory.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Unless I missed something, all remaining instance of all macros are in
files where it makes sense to use these. I went over the output of:
git grep -c -E 'MBEDTLS_(MD5|RIPEMD160|SHA[0-9]*)_C'
and I think all the files listed fall into one of the following
acceptable categories:
- documentation and historical documents: Changelog, docs/**/*.md
- config files and related: mbedtls_config.h, configs/*.h,
check_config.h, config_psa.h, etc.
- scripts that build/modify configs: all.sh, depends.py,
set_psa_test_dependencies.py, etc.
- implementation of MD or PSA or related: md.h, psa_util.h, etc. and
corresponding test suites
- implementation of hashes: md5.c, sha256.h, etc. and corresponding test
suites
- two example programs using a low-level hash API: hash/hello.c,
pkey/ecdsa.c
- test/benchmark.c, test/selftest.c: actually want our built-in
implementations
- a function in test_suite_psa_crypto_storage_format that is
specifically for checking if the hash is built in.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The last line of programs/psa/key_ladder_demo.c is of the following
form:
#endif /* Very long comment ... */
Uncrustify tries to reduce the length:
#endif \
/* Very long comment ... */
and causes a compiler error as there is a continuation line with no
actual code in it. Work around this by linewrapping the comment
in advance.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
After opening a file containing sensitive data, call mbedtls_setbuf() to
disable buffering. This way, we don't expose sensitive data to a memory
disclosure vulnerability in a buffer outside our control.
This commit adds a call to mbedtls_setbuf() after each call to fopen(),
but only in sample programs that were calling mbedtls_platform_zeroize().
Don't bother protecting stdio buffers in programs where application buffers
weren't protected.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Remaining hits seem to be hex data, certificates,
and other miscellaneous exceptions.
List generated by running codespell -w -L
keypair,Keypair,KeyPair,keyPair,ciph,nd
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Visual Studio and CMake didn't like having targets with the same name,
albeit in different directories.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- avoid hardcoded sizes when there's a macro for that
- avoid mutable global variables
- zeroize potentially-sensitive local buffer on exit
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
MSVC 2013, still supported and used in our CI, did not support that.
aead_psa.c(78): error C2099: initializer is not a constant
aead_psa.c(168): error C2057: expected constant expression
aead_psa.c(168): error C2466: cannot allocate an array of constant size 0
aead_psa.c(168): error C2133: 'out' : unknown size
aead_psa.c(169): warning C4034: sizeof returns 0
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Having two programs might make comparison easier, and will make it
easier to people to use just the PSA one as an example.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Existing example programs in this directory are already incompatible
with that option, so this is probably acceptable here too.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is meant to highlight similarities and differences in the
multi-part HMAC APIs.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Change one occurrence of ${PYTHON} to ${MBEDTLS_PYTHON_EXECUTABLE}
and add implied ${MBEDTLS_PYTHON_EXECUTABLE} to the start of a
different command.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
When the option is On, CMake will have rules to generate the generated
files using scripts etc. When the option is Off, CMake will assume the
files are available from the source tree; in that mode, it won't require
any extra tools (Perl for example) compared to when we committed the
files to git.
The intention is that users will never need to adjust this option:
- in the development branch (and features branches etc.) the option is
always On (development mode);
- in released tarballs, which include the generated files, we'll switch
the option to Off (release mode) in the same commit that re-adds the
generated files.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This one's a bit funny too as the generated file is not a source to the
executable (ie, it's not passed as an argument to the compiler), so
CMake's dependency resolution didn't work even though the file is in the
same directory.
For some reason, the following didn't work either:
add_dependencies(psa_constant_names
${CMAKE_CURRENT_BINARY_DIR}/psa_constant_names_generated.c)
So, apply the same strategy as for cross-directory use of a generated
file by creating a target and using it as a dependency.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Also remove preprocessor logic for MBEDTLS_CONFIG_FILE, since
build_info.h alreadyy handles it.
This commit was generated using the following script:
# ========================
#!/bin/sh
git ls-files | grep -v '^include/mbedtls/build_info\.h$' | xargs sed -b -E -i '
/^#if !?defined\(MBEDTLS_CONFIG_FILE\)/i#include "mbedtls/build_info.h"
//,/^#endif/d
'
# ========================
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
