[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