CMS_add0_cert: if cert already present, do not throw error but ignore it#19199
CMS_add0_cert: if cert already present, do not throw error but ignore it#19199DDvO wants to merge 4 commits intoopenssl:masterfrom
CMS_add0_cert: if cert already present, do not throw error but ignore it#19199Conversation
|
This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago |
|
This PR is in a state where it requires action by @openssl/committers but the last update was 61 days ago |
|
Ping for 2nd review |
|
This is a change in behavior, so it probably needs an OTC decision. (There is no OTC meeting for a few weeks). |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago |
|
OTC: This is OK for master if testcase is added and it has a CHANGES.md entry. |
Also add checks on failing cert/CRL up_ref calls; improve coding style.
…ror but ignore it
f20eaa9 to
4da9967
Compare
I've added the requested test case and Looking again at the code I found a potential crash. |
Reviewed-by: Tomas Mraz <[email protected]> Reviewed-by: Paul Dale <[email protected]> Reviewed-by: David von Oheimb <[email protected]> (Merged from #19199)
Also add checks on failing cert/CRL up_ref calls; improve coding style. Reviewed-by: Tomas Mraz <[email protected]> Reviewed-by: Paul Dale <[email protected]> Reviewed-by: David von Oheimb <[email protected]> (Merged from #19199)
|
Merged to master - thanks @t8m and @paulidale for the reviews. |
|
Is there any intent to backport this to 1.1.1 or accept a PR doing so? The old behaviour has been causing problems downstream. In my case specifically, Synology MailPlus fails to sign emails using S/MIME certs issued with a duplicate certificate entry by the CA, such as Sectigo. 1.1.1 is still relied on by a number of hardware vendors, and this is such a small change that to my uninitiated eyes it seems like a good candidate for a backport. Edit: I see that 1.1.1 is going to be EOL very soon. So likely, the answer is no. :) |
|
The answer is no. And this is also not present in 3.0 and 3.1 branches either, because strictly speaking this is not a bug fix and it could break some (fairly special though) use cases. |
Thanks for pointing out the actual reason. |
It makes little sense to forbid adding a cert that was already present
and just causes trouble in case multiple cert sources are combined.
(Side note: After correcting this, the error reason
CMS_R_CERTIFICATE_ALREADY_PRESENTbecomes unused. Yet for strict API compatibility I think we cannot remove it.)Update doc accordingly and remove the wrong statement that a CRL must not be added twice.
On this occasion also add checks on failing cert/CRL up_ref calls and improve coding style.