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
Rich 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.
Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption
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
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
>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
> 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
>"We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as
discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3
PSKs) then we should disable TLSv1.3."
This seems reasonable to me, albeit a bit wordy since you could delete the
first sentence. :)
>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
On 08/08/18 11:28, Matt Caswell wrote:
> For the full background to this issue see:
>
> https://github.com/openssl/openssl/issues/6490
>
> TL;DR summary:
>
> The TLSv1.2 and TLSv1.3 PSK mechanisms are quite different to each
> other. OpenSSL (along with at least GnuTLS maybe others) has
13 matches
Mail list logo
