For the benefit of those in the future getting redirected here by Google (or Bing... which actually was my case), macFUSE is a 'strange beast' for a simple reason: it is 'as open-source as Apple allows it', that is, there is a point where the
core of the kernel extension that macFUSE
has to install requires a valid signature
and a notarisation by Apple — or else, you get all those suspicious warnings popping up all over the place, scaring users off (and — since it's a
kernel extension — there might be certain configurations where macOS won't even install an unsigned/unnotarized kext anyway). Benjamin Fleischer, the original developer, had a tough choice to make. Obviously he wasn't going to keep his Apple developer digital signature around to be used by
anyone — which would get blocked by Apple in no time anyway (and not even entitle him to a refund). The first alternative to that (and I believe that was what he did in the past releases) would be to do both: release the open-source code of the kext (you can still grab it)
but also bundle a signed/notarised binary version for those who trust him, to avoid macOS to trigger DEFCON 5.
For some reason, this became impractical in the
current release cycle. There exist a gazillion reasons for that. Maybe Apple frowned upon a 'parallel' release of open-source code
and a code-signed/notarised kext that
allegedly was compiled from that source code — but the truth is that nobody can know that (possibly not even Apple, if they wished to check on their own). At the end of the day,
if you used Fleischer's compiled/signed/notarised binary, you'd have to trust him that he had, in fact, compiled it from the open source code he also provided; you couldn't
know for sure. You
could check that the kext
was signed by him and notarised by Apple, and that nobody tampered with the code, but... what code? You cannot possibly know.
It is also possible that Apple didn't limit themselves to frowning. They might have alerted Fleischer and told him that his distribution model of a kernel extension — signed and notarised by Apple — was 'not acceptable', and either he changed his approach, or Apple would revoke his current developer license and signature. Again, I'm only speculating what Apple might told Fleischer or not, but I can imagine such a scenario to be
plausible, if not
possible.
Thus, from the current version onwards, Fleischer simply distributed the kext
without the source code. If it's a question of trust anyway, just distributing the kext in binary format as
freeware is perfectly legitimate — freeware is still popular
without open-source code, after all; one thing does not necessarily imply the other, and there is
lots of perfectly safe freeware around
But of course there is nobody (except perhaps Apple) that can
demand that you trust person X or Y, 'just because everybody else does'. Fleischer
has a good reputation — after all, he's still behind the codebase — and macFUSE is still being maintained (while SSHFS probably doesn't really need an update — which it hadn't have since 2014! — simply because, well, the SSH protocol hasn't
really changed since then... and it might only change in a decade or two, when it will need to deal with post-quantum encryption or whatever we'll get in 2040
![Stick Out Tongue :p :p](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
). It is trusted by very-security-conscious companies such as
Keybase — who also bases their code on macFUSE (albeit on an older version, forked by them, exactly because of the issue of signing & notarising bundled software in the
same installer).
In short: there is no reason to
mistrust macFUSE's closed-source, freeware kernel extension. Nevertheless, it's up to you to evaluate the amount of trust you're willing to put on
any software installed on your system. Apple will only guarantee — and even that just to a degree — what you've installed from their App Store; apps 'in the wild' — even those notarised by Apple! — are a different story. There is
always a certain degree of risk; as the old saying goes, any computer connected (directly or indirectly!) to the Internet
is subject to
some risk. We nevertheless use them every day...