Fix usage with sed:
s/MBEDTLS_OR_PSA_WANT_\([A-Z_0-9]*\)/MBEDTLS_HAS_\1_VIA_LOWLEVEL_OR_PSA/
s/MBEDTLS_USE_PSA_WANT_\([A-Z_0-9]*\)/MBEDTLS_HAS_\1_VIA_MD_OR_PSA_BASED_ON_USE_PSA/
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
If there is a PSK involved in the key exchange
and thus no certificate we do not go through the
MBEDTLS_SSL_CERTIFICATE_REQUEST state thus there
is no reason to check that in the coordination
function of that state.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
ECDHE operations have to be done in
ephemeral and PSK-ephemeral key exchange
mode, not just ephemeral key exhange mode.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
lstat is not available on some platforms (e.g. Ubuntu 16.04). In this
particular case stat is sufficient.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
On non-windows environments, when loading certificates from a given
path through mbedtls_x509_crt_parse_path() function, if a symbolic
link is found and is broken (meaning the target file don't exists),
the function is returning MBEDTLS_ERR_X509_FILE_IO_ERROR which is
not honoring the default behavior of just skip the bad certificate file
and increase the counter of wrong files.
The problem have been raised many times in our open source project
called Fluent Bit which depends on MbedTLS:
https://github.com/fluent/fluent-bit/issues/843#issuecomment-486388209
The expected behavior is that if a simple certificate cannot be processed,
it should just be skipped.
This patch implements a workaround with lstat(2) and stat(2) to determinate
first if the entry found in the directory is a symbolic link or not, if is
a simbolic link, do a proper stat(2) for the target file, otherwise process
normally. Upon find a broken symbolic link it will increase the counter of
not processed certificates.
Signed-off-by: Eduardo Silva <eduardo@treaure-data.com>
We had a message in the data file, and were computing its hash in the
test function. It is more efficient (and simpler when it comes to
dependencies) to directly have the message hash in the data file.
It was probably this way because some test vectors provide the message
for the sake of all-in-one implementation that hash-and-sign at once.
But our API gets a hash as the input and signs it. In unit tests, this
should be reflected in the signature of the test function, which should
take a hash as input.
The changes to the .data file were done using the following python
script:
import hashlib
suite = 'pkcs1_v21'
functions = {
'pkcs1_rsassa_pss_sign': (6, 8),
'pkcs1_rsassa_pss_verify': (4, 6),
'pkcs1_rsassa_pss_verify_ext': (4, 8),
}
def hash_ctx(s):
if s == 'MBEDTLS_MD_MD5':
return hashlib.md5()
if s == 'MBEDTLS_MD_SHA1':
return hashlib.sha1()
if s == 'MBEDTLS_MD_SHA224':
return hashlib.sha224()
if s == 'MBEDTLS_MD_SHA256':
return hashlib.sha256()
if s == 'MBEDTLS_MD_SHA384':
return hashlib.sha384()
if s == 'MBEDTLS_MD_SHA512':
return hashlib.sha512()
def fix(l):
parts = l.rstrip().split(":")
fun = parts[0]
if fun not in functions:
return l
(digest_idx, msg_idx) = functions[fun]
alg_str = parts[digest_idx]
if alg_str == "MBEDTLS_MD_NONE":
return l
h = hash_ctx(alg_str)
msg_str = parts[msg_idx]
msg_hex = msg_str[1:-1]
msg = bytes.fromhex(msg_hex)
h.update(msg)
msg_hash = h.hexdigest()
msg_hash_str = '"' + msg_hash + '"'
parts[msg_idx] = msg_hash_str
return ":".join(parts) + '\n'
filename = 'tests/suites/test_suite_' + suite + '.data'
with open(filename) as f:
lines = f.readlines()
lines = [fix(l) for l in lines]
with open(filename, 'w') as f:
f.writelines(lines)
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
