The import-and-save and load-and-check parts of the tests don't have to be
actually the same test cases.
Introduce the terms “forward compatibility” and “backward compatibility” and
relate them to import-and-save and load-and-check actions.
These are clarifications of intent that do not represent an intended change
in the strategy or intended coverage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Remove a check in rsa_rsassa_pkcs1_v15_encode() that
is not needed because the same check is performed
earlier. This check was added in #4707.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Restore the optimization done in
HEAD^{/Speed up the generation of storage format test cases}
which was lost during refactoring made when adding support for
implicit usage flags.
There are still more than one call to the C compiler, but the extra
calls are only for some key usage test cases.
This is an internal refactoring. This commit does not change the
output of generate_psa_tests.py
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We previously introduced a safety check ensuring that if a datagram had
already been dropped twice, it would no longer be dropped or delayed
after that.
This missed an edge case: if a datagram is dropped once, it can be
delayed any number of times. Since "delay" is not defined in terms of
time (x seconds) but in terms of ordering with respect to other messages
(will be forwarded after the next message is forwarded), depending on
the RNG results this could result in an endless loop where all messages
are delayed until the next, which is itself delayed, etc. and no message
is ever forwarded.
The probability of this happening n times in a row is (1/d)^n, where d
is the value passed as delay=d, so for delay=5 and n=5 it's around 0.03%
which seems small but we still happened on such an occurrence in real
life:
tests/ssl-opt.sh --seed 1625061502 -f 'DTLS proxy: 3d, min handshake, resumption$'
results (according to debug statements added for the investigation) in
the ClientHello of the second handshake being dropped once then delayed
5 times, after which the client stops re-trying and the test fails for
no interesting reason.
Make sure this doesn't happen again by putting a cap on the number of
times we fail to forward a given datagram immediately.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
