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

Treat malformed key(pair) as missing in create-key(pair) code paths. #612

Merged
merged 1 commit into from
May 29, 2024

Conversation

arsing
Copy link
Member

@arsing arsing commented May 10, 2024

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.

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.
@arsing arsing merged commit 0351353 into Azure:main May 29, 2024
67 checks passed
@arsing arsing deleted the create-key-treat-malformed-as-missing branch May 29, 2024 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants