On Thu, Aug 09, 2018 at 02:23:07PM -0700, Paul Dale wrote:
> > Real code often doesn't check return values. Even ours. :(
>
> Could we consider adding a lot more __owur tags to functions to encourage
> this?
>
> As an API change it would have to wait for a major release.
This is sometimes a g
; Encryption
Phone +61 7 3031 7217
Oracle Australia
-Original Message-
From: Salz, Rich [mailto:rs...@akamai.com]
Sent: Thursday, 9 August 2018 11:49 PM
To: openssl-project@openssl.org
Subject: Re: [openssl-project] Removal of NULL checks
>it's NULL. Now imagine that this st
On Thu, Aug 09, 2018 at 07:12:18PM +0200, Richard Levitte wrote:
> viktor> X509 *x;
> viktor> STACK_OF(X509) *s;
> viktor>
> viktor> ...
> viktor> /* Allocate 's' and initialize with x as first element */
> viktor> if (sk_X509_push(s = sk_X509_new(NULL), x) < 0) {
>
In message <20180809165255.gg14...@straasha.imrryr.org> on Thu, 9 Aug 2018
12:52:56 -0400, Viktor Dukhovni said:
viktor> On Thu, Aug 09, 2018 at 06:40:14PM +0200, Richard Levitte wrote:
viktor> > In message <20180809162245.gd14...@straasha.imrryr.org> on Thu, 9 Aug
2018 12:22:45 -0400, Viktor D
On Thu, Aug 09, 2018 at 06:40:14PM +0200, Richard Levitte wrote:
> In message <20180809162245.gd14...@straasha.imrryr.org> on Thu, 9 Aug 2018
> 12:22:45 -0400, Viktor Dukhovni said:
>
> openssl-users> It needs to be possible to recompile and run without auditing
> code.
> openssl-users> The wor
In message <20180809162245.gd14...@straasha.imrryr.org> on Thu, 9 Aug 2018
12:22:45 -0400, Viktor Dukhovni said:
openssl-users> It needs to be possible to recompile and run without auditing
code.
openssl-users> The worst kind of incompatibilities are those that are not
reported
openssl-users>
On Thu, Aug 09, 2018 at 05:53:11PM +0200, Richard Levitte wrote:
> I think we need to be a bit more nuanced in our views. Bug fixes are
> potentially behaviour changes (for example, I recently got through a
> PR that added a stricter check of EVP_PKEY_asn1_new() input; see #6880
> (*)).
We went
In message <8acbebbf-f4a2-469f-bb5b-3564a24dc...@dukhovni.org> on Thu, 9 Aug
2018 11:02:16 -0400, Viktor Dukhovni said:
openssl-users>
openssl-users>
openssl-users> > On Aug 9, 2018, at 9:49 AM, Salz, Rich
wrote:
openssl-users> >
openssl-users> > This is another reason why I am opposed to N
>Whether one's for them, or against them, removing a check
from a function that would formerly return an error and
making it crash is a substantial API change.
I don't disagree.
___
openssl-project mailing list
openssl-project@openssl.org
> On Aug 9, 2018, at 9:49 AM, Salz, Rich wrote:
>
> This is another reason why I am opposed to NULL checks.
Whether one's for them, or against them, removing a check
from a function that would formerly return an error and
making it crash is a substantial API change. We must
avoid API changes
>it's NULL. Now imagine that this stack was some kind of deny list. If
>entry producer didn't pay attention to error when creating stack and
>putting things into it, consumer would be led to belief that there is
>nothing to deny and let through the requests that are supposed to be
>
> Should not be changed period. Even across major release boundaries.
> This is not an ABI compatibility issue, it is a source compatibility
> issue, and should avoided all the time. If we want to write a *new*
> function that skips the NULL checks it gets a new name.
While I admittedly crossed
18 11:52 PM
To: openssl-project@openssl.org
Subject: Re: [openssl-project] Removal of NULL checks
> On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote:
>
> However in the context of removing such checks - that we should not be
> doing - the behaviour of the APIs in this area should not
On Wed, Aug 08, 2018 at 08:19:24PM +1000, Tim Hudson wrote:
> We don't have a formal policy of no NULL checks - we just have a few
> members that think we should have such a policy but it has never been voted
> on as we had sufficiently varying views for a consensus approach to not be
> possible.
>
> On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote:
>
> However in the context of removing such checks - that we should not be doing
> - the behaviour of the APIs in this area should not be changed
Should not be changed period. Even across major release boundaries.
This is not an ABI compatibil
We don't have a formal policy of no NULL checks - we just have a few
members that think we should have such a policy but it has never been voted
on as we had sufficiently varying views for a consensus approach to not be
possible.
Personally I'm in favour of high-level APIs having NULL checks as it
We've had a policy for a while of not requiring NULL checks in
functions. However there is a difference between not adding them for new
functions and actively removing them for old ones.
See https://github.com/openssl/openssl/pull/6893
In this case the removal of a NULL check in the stack code ha
17 matches
Mail list logo