I don't know if KSJailbreak.h needs to be added to a namespacing list. generate.sh script did not change anything related to it.

I actually just changed this a few weeks ago to a much simplified version, and I think this PR changes it back. Is there a reason in particular? It's not actually really useful for a crash reporter (it is sort of useful for an app to know). The implementation was very slow and did a lot too much vs. the current one which simply writes somewhere that is sandboxed.

Is jailbreaking not possible without also breaking app sandboxing?

@naftaly @kstenerud Included Alex's sandbox check in the new Jailbreak macro, updated other filename to omit "bugsnag" ;)

@naftaly @kstenerud Included Alex's sandbox check in the new Jailbreak macro, updated other filename to omit "bugsnag" ;)

My issue wasn't that the new code was missing, it's that this PR adds a lot of checks that 99.9% of users will have go through because they're probably not jailbroken. This is a perf issue that I'd prefer not to have. My take is that a small simple sandbox check should be enough get most jailbreakers without a large perf hit. If anyone wants more, it's not really a crash reporter thing, it's an app thing. And most times, you can see if the app is jailbroken through the stack trace.

The checks themselves are trivially fast (5 syscalls and an ENV check), so there are no perf issues to speak of. As well, this is resilient to countermeasures because it's a macro that directly makes syscalls, making it VERY annoying to patch out (you'd have to do separate searches and patches per-app, per release - rather than a global solution that works everywhere such as patching the open() call in the C runtime library).

This isn't a 100% solution, but it is solid enough that many big companies have been mollified by its existence. And if they want even more security (banking apps, for example), they can get dedicated engineers to play the cat-and-mouse game full time.

I would, however, like to have the existing sandbox check in addition to the others, just to catch soft jailbreaks that try to make it look like the system integrity is still intact.

@kstenerud I added the existing sandbox check in line 213 in the new file.

.. so there are no perf issues to speak of...

Definitely your call. But when we're talking about app startup every millisecond counts and this is definitely adding some. If you go even further and look at the calls to dyld being made, these can cause lock contention due to library loading early in the program. When I say perf issues, I meant that we're using up more time than required at startup and this can be a showstopper for some.