* In a production environment, it is almost never appropriate to simply
crash in an uncontrolled manner (i.e. dereferencing a NULL pointer).
Applications that want this can check parameters themselves before calling the
function.
Saying “C arguments don’t hold” is only because it goes
if (!ossl_assert(ptr != NULL)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
If the project decides to do this, I would like a configure option to ONLY turn
on ossl_assert so that previous behavior can be restored without debug
On 29/11/2019 10:29, Matthias St. Pierre wrote:
>
>
> On 29.11.19 10:22, Matt Caswell wrote:
>>
>> if (!ossl_assert(ptr != NULL)) {
>> ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
>> return 0;
>> }
>>
>
> I still dislike the odd way in which the
On 29.11.19 11:29, Matthias St. Pierre wrote:
On 29.11.19 10:22, Matt Caswell wrote:
if (!ossl_assert(ptr != NULL)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
I still dislike the odd way in which the assertion needs to be
On 29.11.19 10:22, Matt Caswell wrote:
if (!ossl_assert(ptr != NULL)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
I still dislike the odd way in which the assertion needs to be formulated,
with the double negation. With the
Oops, you are correct. I was under the mistaken impression that ossl_assert
compiled to nothing outside of debug mode.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 29 Nov 2019, at 7:22 pm, Matt Caswell wrote:
>
On Fri, Nov 29, 2019 at 7:08 PM Tomas Mraz wrote:
> The "always check for NULL pointers" approach does not avoid
> catastrophical errors in applications.
I didn't say it avoided all errors (nor did anyone else on the thread that
I've read) - but it does avoid a whole class of errors.
And for
On 29/11/2019 08:38, Dr Paul Dale wrote:
> I’d prefer option 1 or the middle ground. I’ve lost count of the
> number of times I’ve seen programs crashing in the crypto library
> which required mammoth debugging efforts to irrefutably demonstrate
> that the caller is at fault rather than the
The "always check for NULL pointers" approach does not avoid
catastrophical errors in applications. For example let's say an
application code encrypts some plaintext in-place and sends it out as
encrypted. Let's say we check for the NULL EVP_CIPHER_CTX in
EVP_CipherUpdate() but the app does not
I’d prefer option 1 or the middle ground. I’ve lost count of the number of
times I’ve seen programs crashing in the crypto library which required mammoth
debugging efforts to irrefutably demonstrate that the caller is at fault rather
than the crypto library :(
Option 1 would be preferable
The way I view the issue is to look at what happens when things go wrong -
what is the impact - and evaluate the difference in behaviour between the
approaches.
You have to start from the premise that (in general) software is not tested
for all possible usage models - i.e. test coverage isn't at
On Thu, 2019-11-28 at 11:19 -0800, Benjamin Kaduk wrote:
> On Wed, Nov 27, 2019 at 10:38:41AM +0100, Richard Levitte wrote:
> > Depending on who you're asking, you get different responses.
> >
> > The topic is: should we check pointers coming from applications
> > before
> > using them or not?
>
On Wed, Nov 27, 2019 at 10:38:41AM +0100, Richard Levitte wrote:
> Depending on who you're asking, you get different responses.
>
> The topic is: should we check pointers coming from applications before
> using them or not?
>
> There are two positions on this:
>
> 1. Yes we should so we don't
On Wed, 27 Nov 2019 11:53:01 +0100,
Dr. Matthias St. Pierre wrote:
>
> FYI: there was a related discussion a year ago on GitHub about an
> ossl_is_null() macro,
>
> https://github.com/openssl/openssl/pull/7218
>
> which ended up undecided.
Thank you. I had totally forgotten that one, so
Depending on who you're asking, you get different responses.
The topic is: should we check pointers coming from applications before
using them or not?
There are two positions on this:
1. Yes we should so we don't crash processes unnecessarily, and we
should return an error if pointers are
15 matches
Mail list logo
