Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Alpha1 Test merge #11520

Closed

Conversation

mattcaswell
Copy link
Member

This is a test merge of all the key outstanding alpha1 PRs to make sure everything works together. I don't ever plan to merge this specific PR. I will close it when all the PRs it is using have been merged (or when its no longer useful).

While doing this I uncovered a number of problems - many of which I've noted in the outstanding PRs where applicable. In other cases I've had to implement new fixes and workarounds to get it working - which I will raise as new PRs.

This includes the following PRs:
#11328
#11303
#11332
#11371
#11494
#11507
#11508
#11511

This means that, with this PR, we are finally able to to sslapitest and ssl_test_new run all the way through using the FIPS provider. I would still like to tackle ssl_test_old.

All tests are passing locally. Lets see what the CIs make of it.

levitte and others added 30 commits April 10, 2020 22:52
The macros are converted to functions, and are modified to support
provider implementations.
The reason to do this is many-fold.  We need EC key generation for
other work.  However, SM2 are currently closely related to EC keys
with legacy methods, but not with provider methods.

To avoid having to wait on provider support for SM2, we temporarly
do an extra check for what the legacy methods identify as SM2 keys
(either the EVP_PKEY_SM2 pkey id was used, or the SM2 curve), and
redirect to legacy code in one case, and in the other case, we
forcedly downgrade provider side EC keys with SM2 curves to legacy
SM2 keys, using available tools.
Moved some shared FFC code into the FFC files.
Added extra paramgen parameters for seed, gindex.
Fixed bug in ossl_prov util to print bignums.
Specifically for x25519, x448, ed25519 and ed448.
There were a few places where we were not passing through the libctx
when constructing and EVP_PKEY_CTX.
We also don't load the default provider into the default libctx to make
sure there is no accidental "leakage".
The Ed448 private key decoding makes algorithm fetches. Therefore we teach
d2i_PrivateKey et al about libctx and make sure it is passed through the
layers.
The Ed448 private key deconding needs to use a library ctx. So we
implement a priv_decode_with_libctx function for it.
We restrict this to just the PrivateKey loading code at the moment.
Now that d2i_PrivateKey_ex() and other similar functions exist we should
use it when loading a PEM PrivateKey.
Since loading a private key might require algorithm fetches we should
make sure the correct libctx is used.
This is the same as X509_verify() except that it takes a libctx and propq
parameter and signature verification is done using those.
The internal version is library context aware.
We also prepare the way for a future commit to run ssl_test_new with
just the FIPS provider loaded.
…ders

We now run the tests twice: Once with no specific providers loaded and
just using the default libctx, and a second time with a non-default libctx
and the default provider.

In the second run we disable tests which use a PSS cert/key because we
don't yet have support for that.
We load the FIPS module and make sure it is configured before running
the ssl_test_new tests.
In a similar way the commit 76e23fc we must ensure that we use a libctx
whenever we call EC_POINT_point2buf because it can end up using crypto
algorithms.
Previously import_to just took an EVP_PKEY as the argument. However we
need to some additional context data as well - specifically the libctx.
Therefore we pass an EVP_PKEY_CTX instead to hold the combination of
both of these things.
We had a spot where a fatal error was occurring but we hadn't sent an
alert. This results in a later assertion failure.
@mattcaswell mattcaswell added the branch: master Merge to master branch label Apr 10, 2020
@mattcaswell mattcaswell added this to In progress in 3.0 New Core + FIPS via automation Apr 10, 2020
@mattcaswell
Copy link
Member Author

Updated to additionally include the commits from #11534. This now includes everything that I think should be in the alpha1 release.

@mattcaswell
Copy link
Member Author

Everything in this PR has now been included in other PRs and merged - so closing.

3.0 New Core + FIPS automation moved this from In progress to Done Apr 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
branch: master Merge to master branch
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

4 participants