[openssl-dev] OS X 10.8, x86_64: 01-test_abort.t... sh: line 1: 71522 Abort trap: 6

[Kurt Roeckx]

On Sat, Mar 19, 2016 at 07:41:28PM -0400, Jeffrey Walton wrote:
> On Sat, Mar 19, 2016 at 7:31 PM, Richard Levitte <levitte at openssl.org> wrote:
> > In message <rt-4.0.19-1915-1458428897-111.4451-6-0 at openssl.org> on Sat, 19 Mar 2016 23:08:17 +0000, "noloader at gmail.com via RT" <rt at openssl.org> said:
> >
> > rt> On Sat, Mar 19, 2016 at 6:44 AM, Richard Levitte via RT <rt at openssl.org> wrote:
> > rt> > I think that's a discussion that deserves its own new thread on openssl-dev.
> > rt> >
> > rt> > A RT ticket is *not* the right place for a philosophical discussion. Closing
> > rt> > this. Please don't respond on this message, create a new thread instead.
> > rt>
> > rt> Thanks Richard.
> > rt>
> > rt> For me, its not open for debate. Its a point of data egress, so it
> > rt> must not occur. What others do is there business.
> > rt>
> > rt> I'll configure without the "data loss" feature, and others can do what
> > rt> they want :)
> >
> > Well, how about you go after the calls then.  Complaining about the
> > existence of OPENSSL_die or OPENSSL_assert is about as fruitful as
> > complaining about the existence of abort() or assert()...  That's how
> > this "philosophical discussion" started out that that's your
> > complaint, isn't it?  If not, I'd like you to clarify.
> 
> Allowing a library to make policy decisions for the application is a
> philosophical debate.

At least a few of us don't want asserts in the library in the
normal version and think that it should be up to the
application to decide what to do.

I think we need something that for a debug build it triggers an
abort (or whatever), but that for normal builds returns an error
instead.

> Allowing data to egress from the security boundary violates security
> policies, and its not philosophical.

I hope that core files aren't just send to a third party without
at least asking the user.  But I understand that at least Windows
is doing this by default now without being able to turn it off.

If the assert we added actually sees that things are in such a bad
state that we'll likely crash soon anyway, it doesn't change much.

And I guess the question is if the error is something we can
recover from or not.


Kurt