Treat malformed key(pair) as missing in create-key(pair) code paths. #612
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the case of a key pair, a malformed file is one that openssl fails to parse as a PEM private key blob.
In the case of (symmetric) keys, any file is a valid key except for an empty file, so we check for that. Depending on the filesystem, it is technically possible that a file is non-empty but truncated, say because it had two disk extents but only the first one was written to disk successfully, and this code would not detect that. But that is unlikely to happen, especially since symmetric keys are generally very small.
This special-casing of malformed keys is only done for filesystem keys. Right now the only trigger we know of is that an ungraceful shutdown can result in a malformed file, so this commit handles that case. A PKCS#11 library on the other hand is expected to save and return only valid objects, so if it has some reason to fail we should evaluate that based on the specific library and error code situation when it happens, ie someone encounters it and reports it to us.