This is in keeping with other generated files (such as generated .data
files) that are added to releases.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
* restricted/development-restricted: (30 commits)
Tiny fix in ChangeLog pt 2
Tiny fix in ChangeLog
Changelog entry for the RSA memory leak
Edit ChangeLog entry
Update ChangeLog
Add test cases for extKeyUsage
Rationalize extKeyUsage tests
Use P_CLI when O_CLI's status is not reliable
Rationalize keyUsage testing, round 2
Always print detailed cert errors in test programs
Fix 1.3 failure to update flags for (ext)KeyUsage
Rationalize ssl-opt tests for keyUsage
Test cert alert KEY_USAGE -> UNSUPPORTED_CERT
Free allocated memory where methods were returning without freeing
Force MBEDTLS_PSA_HMAC_DRBG_MD_TYPE based on CTR_DRBG
Document that MBEDTLS_PSA_HMAC_DRBG_MD_TYPE does not force HMAC
Clean up constant-flow memsan testing
Improve description of who is affected
More diversified sizes in tests
Fix stack buffer overflow in ECDSA signature format conversions
...
We are technically allowed to use all possible values of key slice index
that will fit into the bit width we have allocated, so allow all values.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The persistent key cache slice is the last slice (not the first as
previously stated). Update the numbering-related comments accordingly.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Generally speaking, in this group of test we use O_SRV when testing our
client's behaviour, and O_CLI when testing our server's behaviour. I
don't think that's essential, but why not.
Well, for these two tests there's a reason why not: O_CLI often exits 0,
seemingly not minding that the server aborted the handshake with a fatal
alert, but sometimes it exits 1. (I've observed 0 on my machine, on two
runs of OpenCI and Internal CI, and 1 in some test in one run of
Internal CI.)
So, use our client instead, which exits non-zero consistently.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- cli-auth 1.2 was missing a test with an irrelevant bit set in addition
to the relevant bit (which was added for 1.3 previously)
- use consistent naming for fail (hard/soft)
Note: currently there are no "fail (soft)" cases for 1.3 authentication
of server by client, as server auth is mandatory in 1.3 (this will
change in 3.6.1).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Previously the client was only printing them on handshake success, and
the server was printing them on success and some but not all failures.
This makes ssl-opt.sh more consistent as we can always check for the
presence of the expected message in the output, regardless of whether
the failure is hard or soft.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- consistent naming with explicit version
- in each section, have a positive case with just the needed bit set,
and one with an irrelevant bit set in addition (cli 1.3 only had the
former, and cli-auth 1.3 only the later)
- when auth_mode optional is supported failing cases should come in
pairs: soft+hard, this wasn't the case for cli-auth 1.3. (Note: cli 1.3
currently does not support auth_mode optional.)
- failing cases should check that the correct flag is printed and the
expected alert is sent.
The last (two) points have uncovered a bug in 1.3 code:
- In fail (hard) cases the correct alert isn't send, but a more generic
one instead.
- In fail (soft) cases the issue with the certificate is not reported,
actually the certificate is reported as valid.
Both share the same root cause: the flags are not updated properly when
checking the keyUsage extension. This will be addressed in future
commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In terms of line coverage, this was covered, except we never checked the
behaviour was as intended.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Erroring on a symmetric-key type would actually be an extra line of
code.
In theory we could try to save that one line of code, but it is
premature optimisation at this point. Also, this is a predominantly
asymmetric crypto feature, it is less confusing/more user friendly if we
don't allow symmetric keys here.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We shouldn't return PSA_SUCCESS from a function that isn't implemented.
PSA_ERROR_NOT_SUPPORTED seems like the most appropriate return status
for a function that isn't implemented.
Signed-off-by: Janos Follath <janos.follath@arm.com>
