Source code isn't really necessary. Nor sufficient for that matter even if it was there, you'd need verifiable builds and an assurance of no self updating capability too, basically for certain minimal products you need some level of trust. As far as extra verifying though you'd probably start the same way you would minimally blackbox anything: stick it on a virgin test box and monitor all I/O in a controlled setting (VM could work too, though if you're super paranoid you might take into account that can be detected and runtime behavior modified). I guess you could start disassembling it and poking around its memory and such too if you wanted.
But seriously, it's a Mac product, so source access everywhere should kind of obviously be off your list already. How do you know when Apple spies on you? You won't find the source code. And the answer is you blackbox it and mostly you trust that it'd get noticed at some point and Apple would get the crap sued out of them and be investigated by governments worldwide etc etc. Objective Development is a very long standing dev and has put out a far more critical long standing security product that has been used by a lot of sec people for a very long time. Sure they could be compromised in the same way any dev could, but on the lowest critical factor level they're unlikely to be the biggest risk in most users' threat model.
https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
Do check out David Wheeler’s 2009 thesis on Double Diverse Compiling for instance: https://dwheeler.com/trusting-trust/
I don't meant to detract from the "trusting trust" question, there are lots of issues which really are best handled by just pushing the problem problem outside the average user's threat model. Even source-code verification isn't actually terribly robust on the user level: are you sure you got a clean install? Are you sure nothing has modified it? And so at a certain point "just trust Apple" is entirely reasonable.
But I do think we sometimes rely on webs of trust, elaborate app signing schemes, and other software or legal solutions when we could be getting by with a simple hardware answer. (And the entire IoT domain looks a lot like undoing solved hardware problems...)
Actually it is sufficient. On macOS one can install homebrew and add the build from source option. Most Linux distributions provide similar facilities.
Of course on can go Hardcore and use Gentoo, but yeah, in that case verified builds + OSS are the more efficient option unless on has access to a cluster.
Most just unpack the stage3, follow the handbook, and be on their merry way. Hell, I'm super paranoid and I haven't bootstraped on every install.
It's definitely not something I'd ever trust completely, not only could it be spying on you, but I also don't really trust my hardware. However, I must say, it's still very nice to have. It at least narrows the possible spying vectors, and it's nice to know immediately what apps are listening; the best example being Android Studio emulator: always listening.
https://www.theregister.co.uk/2016/08/03/mac_firewall_little...
So you have to implicitly trust the ObDev guys, and you have to implicitly trust the hardware, but beyond those two assumptions they function great for any other threat models.
Would still be nice if they were both open source but hey: I use the open source vscode and it phones home uncontrollably all the time, so source code only benefits us so much.
>Would still be nice if they were both open source but hey: I use the open source vscode and it phones home uncontrollably all the time, so source code only benefits us so much
Yup; definitely true.
At some level in the chain you put your trust in an authority.
Ideally the kind of authority who has more to lose than to gain from spying on their users.