-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
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
Fix some decoder issues including a regression #21603
Conversation
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders.
We're always supposed to add the fallback "unsupported" error if we don't have anything better. However in some cases this wasn't happening because we were incorrectly setting "flag_construct_called" - even though the construct function had failed.
The PEM_read_bio_Parameters[_ex] function does not have the capability of specifying a password callback. We should not use the fallback password callback in this case because it will attempt to send a prompt for the password which might not be the correct thing to do. We should just not use a password in that case. Fixes openssl#21588
We must not ask for a password when attempting to read parameters.
Okay for master of course. This does seem enough like a bug fix to be considered for backfit if @t8m thinks it should go into 3.1 and 3.0. |
Yes, imo this is bug fix and should go to all 3.x branches. |
ok = (rv > 0); | ||
if (ok) | ||
if (ok) { | ||
data->flag_construct_called = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is correct behavior then it may be worth changing the name of the 'flag_construct_called', since technically beforehand it is doing what was described i.e. the constructor was called..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no objection to @mattcaswell renaming it - I don't particularly find the current names all that enlightening.
My approval stands with or without the renaming being suggested by @slontis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems to be more "refactor" than bug fix which I'd rather not do in this PR since it is aimed at backport.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am actually not sure if this change hasn't some other unwanted consequences. Apparently the test suite passes but there might be a performance impact or some corner cases (which we do not test) might be broken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt it will cause much problem. There are very few places where this flag is ever read. It's read in OSSL_DECODER_from_bio
to determine whether to add an error to the stack or not (which is actually the reason for this fix, because it was omitting adding an error in cases where it should). It's also read later on in the same function to determine whether a following decoder successfully called construct (and therefore we should stop looking).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I am fine with merging this now. But perhaps @levitte could look at the consequences when he returns from his vacation.
Trivial fixup pushed (whitespace only), addressing @slontis's comment. I assume the approvals still stand. |
24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually. |
ok = (rv > 0); | ||
if (ok) | ||
if (ok) { | ||
data->flag_construct_called = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I am fine with merging this now. But perhaps @levitte could look at the consequences when he returns from his vacation.
Merged to master, 3.1 and 3.0 branches. Thank you. |
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603)
We're always supposed to add the fallback "unsupported" error if we don't have anything better. However in some cases this wasn't happening because we were incorrectly setting "flag_construct_called" - even though the construct function had failed. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603)
The PEM_read_bio_Parameters[_ex] function does not have the capability of specifying a password callback. We should not use the fallback password callback in this case because it will attempt to send a prompt for the password which might not be the correct thing to do. We should just not use a password in that case. Fixes #21588 Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603)
We must not ask for a password when attempting to read parameters. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603)
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603) (cherry picked from commit 6207f2b)
We're always supposed to add the fallback "unsupported" error if we don't have anything better. However in some cases this wasn't happening because we were incorrectly setting "flag_construct_called" - even though the construct function had failed. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603) (cherry picked from commit 564e5b7)
The PEM_read_bio_Parameters[_ex] function does not have the capability of specifying a password callback. We should not use the fallback password callback in this case because it will attempt to send a prompt for the password which might not be the correct thing to do. We should just not use a password in that case. Fixes #21588 Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603) (cherry picked from commit 0d0791e)
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603) (cherry picked from commit 6207f2b)
We're always supposed to add the fallback "unsupported" error if we don't have anything better. However in some cases this wasn't happening because we were incorrectly setting "flag_construct_called" - even though the construct function had failed. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603) (cherry picked from commit 564e5b7)
The PEM_read_bio_Parameters[_ex] function does not have the capability of specifying a password callback. We should not use the fallback password callback in this case because it will attempt to send a prompt for the password which might not be the correct thing to do. We should just not use a password in that case. Fixes #21588 Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21603) (cherry picked from commit 0d0791e)
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603)
We're always supposed to add the fallback "unsupported" error if we don't have anything better. However in some cases this wasn't happening because we were incorrectly setting "flag_construct_called" - even though the construct function had failed. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603)
The PEM_read_bio_Parameters[_ex] function does not have the capability of specifying a password callback. We should not use the fallback password callback in this case because it will attempt to send a prompt for the password which might not be the correct thing to do. We should just not use a password in that case. Fixes openssl#21588 Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603)
We must not ask for a password when attempting to read parameters. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603)
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603) (cherry picked from commit 6207f2b)
We're always supposed to add the fallback "unsupported" error if we don't have anything better. However in some cases this wasn't happening because we were incorrectly setting "flag_construct_called" - even though the construct function had failed. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603) (cherry picked from commit 564e5b7)
The PEM_read_bio_Parameters[_ex] function does not have the capability of specifying a password callback. We should not use the fallback password callback in this case because it will attempt to send a prompt for the password which might not be the correct thing to do. We should just not use a password in that case. Fixes openssl#21588 Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603) (cherry picked from commit 0d0791e)
We must not ask for a password when attempting to read parameters. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#21603) (cherry picked from commit df3d609)
The PEM_read_bio_Parameters[_ex] function does not have the capability of specifying a password callback. We should not use the fallback password callback in this case because it will attempt to send a prompt for the password which might not be the correct thing to do. We should just not use a password in that case.
#Fixes #21588
While fixing the above I noticed some other odd behaviour with the decoders and fixed that too.
We're always supposed to add the fallback "unsupported" error if we don't have anything better. However in some cases this wasn't happening because we were incorrectly setting "flag_construct_called" - even though the construct function had failed.
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders.