[openssl-dev] OS X 10.8, x86_64: 01-test_abort.t... sh: line 1: 71522 Abort trap: 6

[Jeffrey Walton]

> 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