Open levitte opened 3 years ago
IMO we should do 2. for now, because 1. is clearly a bug. And if there is a fix available to provide 3. during beta phase I think it should be acceptable as a bug fix.
Can we actually read such files that claim to be traditional files but aren't?
@kroeckx, I haven't really tested. Will do
Marking as inactive, to be closed at the end of 3.4 dev barring further input
While making
PEM_write_bio_PrivateKey_traditional()
more strict (see #12728 and #12729), I discovered that our own (legacy in 3.0) backends do not always support traditional output, but sincePEM_write_bio_PrivateKey_traditional()
didn't check that too closely, some "traditional" output may be PKCS#8 after all.DH is one example, I haven't investigated others.
I just tested a little with the openssl installed a part of my system:
So basically, you end up getting a PEM file where the headers indicate "traditional", but the contents are PKCS#8 all the same.
Has anyone ever noticed? I suspect that most people have switched to PKCS#8 anyway, so these kinds of bugs go unnoticed for quite a while.
The question is what to do with this. Letting
PEM_write_bio_PrivateKey_traditional()
output things like the above don't seems right, and squarely contradict the documented intention (fromman PEM_write_bio_PrivateKey_traditional
):I can see several possibilities: