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.