On Sat, Mar 19, 2016 at 07:41:28PM -0400, Jeffrey Walton wrote: > On Sat, Mar 19, 2016 at 7:31 PM, Richard Levitte <levi...@openssl.org> wrote: > > 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: > > > > rt> On Sat, Mar 19, 2016 at 6:44 AM, Richard Levitte via RT > > <r...@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 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev