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

Richard Levitte levitte at openssl.org
Sat Mar 19 23:50:28 UTC 2016


In message <CAH8yC8k56_LZ63fXpdRHRBkOa0DUOzAnqgOyqBV7Dvco9Mxw-Q at mail.gmail.com> on Sat, 19 Mar 2016 19:41:28 -0400, Jeffrey Walton <noloader at gmail.com> said:

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

The few places we're using something that drastic is when the internal
structures can only be seen as corrupt by our own fault.  That's a
point where you can expect things to go crashing any time, or just
becoming *more* corrupt.  The application cannot make a policy
decision at that point, as the virtual rugg has already been pulled
from under everyone's feet.

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

Like I said, find the OPENSSL_die / OPENSSL_assert calls that have
that potential (and the rugg hasn't already been pulled if they get
triggered) and open tickets on them.

However, doing so by point at a test that checks that our testing
framework correctly catches an aborting process wasn't the best place
to go looking....  We have that test in place because, just a few days
ago, the testing framework would miss those.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/


More information about the openssl-dev mailing list