In message <cah8yc8nwf5n7rou-+2ajc1ahhkjdeb-g746eytvfbqnura-...@mail.gmail.com> on Sat, 19 Mar 2016 20:09:34 -0400, Jeffrey Walton <[email protected]> said:
noloader> > noloader> Allowing a library to make policy decisions for the application is a noloader> > noloader> philosophical debate. noloader> > noloader> > The few places we're using something that drastic is when the internal noloader> > structures can only be seen as corrupt by our own fault. That's a noloader> > point where you can expect things to go crashing any time, or just noloader> > becoming *more* corrupt. The application cannot make a policy noloader> > decision at that point, as the virtual rugg has already been pulled noloader> > from under everyone's feet. noloader> noloader> Then why not call exit() rather than abort()? (Regardless of what you noloader> do here, its going to violate Apple's App Store policies and probably noloader> cause a rejection). I just grepped through the source, and we never call OPENSSL_die() directly, we do it via OPENSSL_assert() (well, except for that test program, but the effect is the same for the purpose of that test) Point is, if any of the the assertions are triggered into faulting, there's a but in the library and it shouldn't get released. That's the whole point. The tests are supposed to catch those and basically raise a big red flag. Are you telling me that according to Apple's App Store policies, assertions must not be used? noloader> Also, when configured with -d, that kind of puts you in a debug noloader> configuration. What's the purpose of crashing when the program is noloader> under a debugger? It seems like a raise(SIGTRAP) to snap the debugger noloader> would be a better choice. Well... the implementation of OPENSSL_assert() mimics the implementation of assert(). noloader> How many times has a user submitted a core dump from an abort()? noloader> I'm guessing very few, and they probably got a curt response from the dev noloader> team. Nope, no coredumps, but we do get reports about the failed assertion messages. There was some reported not so long ago, because a couple of assertions I had added were a bit overzealous... but they did also lead us to find a couple bugs in a CRTL. Other than that report, I can't remember when I last saw one. If the library crashes with an assertion failure, I would expect that to be reported, about the same way as a failing "make depend" or other build. If such reports are few and far apart, one might also think that's how often those assertion do fail, or that we've caught them ourselves first. noloader> How many times has OpenSSL perused Apple's, Microsoft's, or <favorite noloader> distros> error reporting website, and opened tickets based on the noloader> error reports? I'm guessing 0. I would believe that when we find errors in other libraries, we do report them if possible. I recently reported a couple of faults in the VMS C RTL (yup, that's the one I mentioned above). noloader> How many times does the report egress data? 100% of the time. noloader> noloader> On the more sarcastic side, NSA, GCHQ and law enforcement has probably noloader> browsed those reports more than the folks they are supposedly provided noloader> for. -- Richard Levitte [email protected] OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
