> 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.
Then why not call exit() rather than abort()? (Regardless of what you do here, its going to violate Apple's App Store policies and probably cause a rejection). Also, when configured with -d, that kind of puts you in a debug configuration. What's the purpose of crashing when the program is under a debugger? It seems like a raise(SIGTRAP) to snap the debugger would be a better choice. > 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. I'm not sure one leads to the other. How many times has a user submitted a core dump from an abort()? I'm guessing very few, and they probably got a curt response from the dev team. How many times has OpenSSL perused Apple's, Microsoft's, or <favorite distros> error reporting website, and opened tickets based on the error reports? I'm guessing 0. How many times does the report egress data? 100% of the time. On the more sarcastic side, NSA, GCHQ and law enforcement has probably browsed those reports more than the folks they are supposedly provided for. Jeff -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
