In message <cah8yc8k56_lz63fxpdrhrbkoa0duozanqgoyqbv7dvco9mx...@mail.gmail.com> on Sat, 19 Mar 2016 19:41:28 -0400, Jeffrey Walton <noloa...@gmail.com> said:
noloader> On Sat, Mar 19, 2016 at 7:31 PM, Richard Levitte <levi...@openssl.org> wrote: noloader> > In message <rt-4.0.19-1915-1458428897-111.4451-...@openssl.org> on Sat, 19 Mar 2016 23:08:17 +0000, "noloa...@gmail.com via RT" <r...@openssl.org> said: noloader> > noloader> > rt> On Sat, Mar 19, 2016 at 6:44 AM, Richard Levitte via RT <r...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
