brew install: Error: tup has been disabled because it requires closed-source macFUSE

[petemoore]

When attempting to install on a Mac, I hit this issue. I'll try on some other Macs to see if it is specific to my version of macOS or brew etc.

petermoore@Peter-Moores-MacBook-Pro-2:~ $ brew cask install osxfuse
Error: Unknown command: cask
petermoore@Peter-Moores-MacBook-Pro-2:~ $ brew install --cask osxfuse
==> Caveats
`osxfuse` has been succeeded by `macfuse` as of version 4.0.0.

To update to a newer version, do:
  brew uninstall osxfuse
  brew install macfuse

osxfuse requires a kernel extension to work.
If the installation fails, retry after you enable it in:
  System Preferences → Security & Privacy → General

For more information, refer to vendor documentation or this Apple Technical Note:
  https://developer.apple.com/library/content/technotes/tn2459/_index.html

You must reboot for the installation of osxfuse to take effect.

==> Downloading https://github.com/osxfuse/osxfuse/releases/download/osxfuse-3.11.2/osxfuse-3.11.2.dmg
==> Downloading from https://github-releases.githubusercontent.com/1867347/ab8d9600-06f1-11eb-9e31-17e04b5951ce?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credent
######################################################################## 100.0%
==> Installing Cask osxfuse
==> Creating Caskroom directory: /usr/local/Caskroom
We'll set permissions properly so we won't need sudo in the future.
Password:
==> Running installer for osxfuse; your password may be necessary.
Package installers may write to any location; options such as `--appdir` are ignored.
installer: Package name is FUSE for macOS
installer: Installing at base path /
installer: The install was successful.
==> Changing ownership of paths required by osxfuse; your password may be necessary.
🍺  osxfuse was successfully installed!
petermoore@Peter-Moores-MacBook-Pro-2:~ $ brew install tup
Error: tup has been disabled because it requires closed-source macFUSE!

[maparent]

see https://github.com/gromgit/homebrew-fuse

[gittup]

One possibility I was considering is trying to revitalize the ldpreload shim for MacOS. That was how tup originally supported macs, but I believe there was a concern that SIP would prevent ldpreload from working with system binaries (like clang, or tools like cp/python/etc), so tup wouldn't be able to get dependencies that way. I tried ldpreload on my current mac (10.15) and it seems to work though. If it does work, we could remove the FUSE requirement and re-enable tup in Homebrew.

Does anyone know more about SIP and what issues we would have by moving from FUSE to a DYLD_INSERT_LIBRARIES for MacOS?

[petemoore]

Does anyone know more about SIP and what issues we would have by moving from FUSE to a DYLD_INSERT_LIBRARIES for MacOS?

I believe this may be an issue for software which uses a hardened runtime, where I think this type of runtime injection is probably disabled. Note that notarized software has to enable the Hardened Runtime capability. Although it sounds like if you were able to do it, perhaps your clang wasn't built with a hardened runtime?

If fuse isn't a requirement, it may remove some complexity when building a docker image containing tup, and also when launching a docker container that runs tup. Note, I was able to get tup running under docker with these measures:

1. When running tup inside docker, I needed to call docker run with additional options:

docker run -t --cap-add SYS_ADMIN --device /dev/fuse --security-opt apparmor:unconfined ...

2. Somewhat unfortunately, docker build does not seem to offer the same provisions as docker run for enabling capabilities, and therefore I believe it isn't possible to run the tup bootstrap.sh script as part of a docker build command. However, there are several workarounds, such as building tup outside of docker build and simply ADD-ing or COPY-ing the tup binary in the docker image, or instead building tup without calling tup itself (e.g. calling build.sh directly rather than bootstrap.sh), which was my chosen path:

RUN curl -L 'https://github.com/gittup/tup/archive/df26484cf223288d31c248a3d50407f2a336df2b.zip' > tup.zip && unzip tup.zip && cd tup-* && CFLAGS="-g" ./build.sh && mv build/tup /usr/local/bin && cd ..

I'm not sure if any of this would be simpler when using the runtime library injection technique, but if it is, that might be a good reason to use it.

BTW, let me know if you'd like me to make a PR adding details about how to call tup in a docker container, if you think it might be useful to others.

[ryandesign]

So since the use of closed-source fuse is undesirable and using DYLD_INSERT_LIBRARIES may not work due to Apple's increasing restrictions, where does that leave tup? Does it work at all?

[petemoore]

I've forgotten the context from this thread (sorry!), but this is how i am currently installing tup on mac, and I think it was working last time I tried.

[ryandesign]

Ok, so... using fuse.

[ryandesign]

So again: how can tup be built on macOS without macFUSE?