10.11 [Tracking Issue]

[DomT4]

This is essentially a triage of various issues and progress on them. Did the same thing for 10.10 last year and it worked relatively well at keeping everyone in the loop.

This thread will be comment-policed fairly hard; Please keep comments related to failures/issues/etc. If you can reproduce an issue providing a brew gist-logs FORMULA is preferred over a simple 👍 - Thanks!

New issues should still be filed as new issues. This is only a centralised tracking thread rather than a solve-everything-here thread.

Core Fixes:

• Basic recognition of 10.11 was added to Homebrew - 62381a6
• pkg-config files were added for 10.11 - 4a8fcd1
• Better detection and warning of unsupported OS X versions was committed - baaa295.
• Clang version update for 10.11 DP2 added in 11cf300.
• Clang version recognition fixed in 0599646.
• Clang version updated for 10.11 DP4 in df15afd.

Potential Issues:

• Rootless: Bans writing to /System, /usr, /bin, /sbin - So far /usr/local isn't write-protected.
• Permissions can wander off and prevent README overwriting - [El Capitan beta 2] brew update error: unable to unlink old 'README.md' (Permission denied) #41150.
• System OpenSSL: Headers have seemingly been removed from the CLT and Xcode - Git package broken in 10.11 El Capitan #40519 (comment).

Formulae Issues Outstanding:

• Pixman fails to build - pixman fails to build on 10.11 #41056 - Can't find somewhere reliable to report upstream.
• Python can fail to build core extension modules - Python fails to build core extension modules on Xcode-only 10.11 #41085.
• Google-sparsehash fails to build on DP2 - google-sparsehash 2.0.2 doesn't build on Mac OS 10.11 DP 2 #41087 - Upstream report.
• Fltk fails to build on DP3 - fltk fails to build on 10.11 #41581.
• Libgcrypt refuses to build - libgcrypt failed to build on 10.11 #41599 - Upstream report.
• Phantomjs refuses to build - Phantomjs 2.0 fails to install on 10.11 #42249 - The internal Qt fails to compile. Needs updating/patching upstream.
• Clang-format - clang-format failed to build on 10.11 #42221 - You need to symlink /Applications/Xcode-beta.app/ to /Applications/Xcode.app/.
• Ctail refuses to compile - ctail failed to build on 10.11 #42400.
• Cputhrottle dies horribly on finding Boost - cputhrottle failed to build on 10.11 #42394.
• Ccze fails to compile - ccze failed to build on 10.11 #42379.
• Carthage fails to compile, looks like incompatibility with Xcode-Beta Swift - carthage failed to build on 10.11 #42378.
• Bup fails to compile - bup failed to build on 10.11 #42375.
• Arabica fails to compile - arabica failed to build on 10.11 #42369.
• Postgresql fails to compile - Postgres install fails on OSX 10.11 #42223 - Can't find readline, needs investigating.
• Libpeas fails to compile - libpeas failed to build on 10.11 #42685.
• ios-class-guard breaks on trying to find OpenSSL, breaks if you force our OpenSSL - ios-class-guard failed to build on 10.11 #42671.
• Io fails to compile - io failed to build on 10.11 #42670.
• Idris fails to compile - idris failed to build on 10.11 #42669.
• Gsoap fails to compile - gsoap failed to build on 10.11 #42502.

Formulae Fixed:

• Qt fails to build - qt failed to build on 10.11 #40585, qt failed to build on 10.11 #42370 - A patch needs submitting to Qt's Gerrit for review. They aren't supporting it any more. We've backported a patch for 10.11.
• Python & Python3 - upgrade python breaks pip #40516 - Tim patched python and python3's OpenSSL detection.
• Git - Git package broken in 10.11 El Capitan #40519 - Misty fixed git to stop looking for OpenSSL headers when CommonCrypto is used.
• GCC - Failed to build GCC on 10.11 #40650 - Patch submitted upstream applied in 3291699.
• Pango can fail to build against the second Xcode beta - Pango install fail on 10.11 #41086. FIXED by the third DP, Xcode 7 Beta.
• Qt5 refuses to build - qt5 5.5.0 fails to build on OSX 10.11 #42014 - Should be fixed by d0020e7.
• MongoDB fails to build - mongodb doesn't build on 10.11 #40955 - Fixed upstream, merged into Homebrew. Should work fine now.
• Rust refuses to build - Rust formula broken with OS X 10.11 public beta #41598 - Upstream report. Fixed upstream, will be fixed here when rust 1.2.0 #42642 is merged.
• Zookeeper fails to compile with htonll problems - zookeeper failed to build on 10.11 #42374. Fixed by e00142f.

[geoff-nixon]

Rootless: Bans writing to /System, /usr, /bin, /sbin - So far /usr/local isn't write-protected.

Correct me if I'm wrong, but I believe this is an issue; if you have a /usr/local already created at the time you upgrade, you're ok, but with a clean install, one cannot create /usr/local.

Adding rootless=0 to nvram boot-args is a workaround, but considering kext-dev-mode=1 wasn't advocated/adopted with 10.10, I think there's good reason to avoid this.

For whatever its worth, I've been using /Users/Shared/Developer/usr/local as my prefix for over a year now, and I have not found the old "if you don't use /usr/local, stuff will break" adage/warning to be true at all. There are some bottles that don't install, of course, but with HOMEBREW_BUILD_FROM_SOURCE set I have not had a single issue.

[MikeMcQuaid]

Correct me if I'm wrong, but I believe this is an issue; if you have a /usr/local already created at the time you upgrade, you're ok, but with a clean install, one cannot create /usr/local.

It'll just require a chown, no?

For whatever its worth, I've been using /Users/Shared/Developer/usr/local as my prefix for over a year now, and I have not found the old "if you don't use /usr/local, stuff will break" adage/warning to be true at all.

You're not getting most binary packages which means stuff is much more likely to break.

[geoff-nixon]

It'll just require a chown, no?

chown... what? You can't chown /usr, and with sudo mkdir /usr/local it acts as though one's trying to to write to a read-only volume (which is, I believe, is basically how "rootless" is implemented).

You're not getting most binary packages which means stuff is much more likely to break.

If you mean I'm not getting the bottled binary packages, yes, those would break; but back in February, PRs #37059 - #37072 were the result of an experiment I did, attempting to install every homebrew formula in this custom directory. Essentially, these were the only ones that failed (for unrelated reasons). I may not have tested each package thoroughly, but I'd say (generally) it was a success.

[MikeMcQuaid]

This doesn't match what I've seen; I've been installing Homebrew fine onto a clean 10.11 VM into /usr/local.

[geoff-nixon]

This doesn't match what I've seen; I've been installing Homebrew fine onto a clean 10.11 VM into /usr/local.

I'll double check.

[geoff-nixon]

This doesn't match what I've seen; I've been installing Homebrew fine onto a clean 10.11 VM into /usr/local.

@MikeMcQuaid Ok you're right, but I'm still (kind of) right-ish:

1. If you upgrade a machine which has an existing /usr/local, the permissions are maintained, and it may or may not writable;
2. I you do a completely clean install, Apple creates a /usr/local, and you can write to this directory (they haven't done that in a while!);
3. I believe (?) if you upgrade a machine which does not have an existing /usr/local when you upgrade, Apple does not create this directory;
4. If /usr/local is deleted (easily done), you cannot re-create it.

So... still a bit of an issue, I'd say ...?

[MikeMcQuaid]

I wouldn't necessarily rely on this behaviour remaining consistent to the actual release, based on past experience. I believe that we should still be able to create that directory somehow.

[geoff-nixon]

I wouldn't necessarily rely on this behaviour remaining consistent to the actual release, based on past experience. I believe that we should still be able to create that directory somehow.

I agree. If there isn't a way to re-create it in later betas, its probably time to raise a stink.

[MikeMcQuaid]

Are you sure it's literally impossible for a sudod user to create those directories with the xattrs?

[geoff-nixon]

Quite — at least by any conventional, reasonable method I know of.

Tests-MacBook-Pro:~ test$ rm -rf /usr/local
Tests-MacBook-Pro:~ test$ mkdir /usr/local
mkdir: /usr/local: Operation not permitted
Tests-MacBook-Pro:~ test$ sudo mkdir -p /usr/local
mkdir: /usr/local: Operation not permitted
Tests-MacBook-Pro:~ test$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
==> This script will install:
/usr/local/bin/brew
/usr/local/Library/...
/usr/local/share/man/man1/brew.1

Press RETURN to continue or any other key to abort
==> /usr/bin/sudo /bin/mkdir /usr/local
mkdir: /usr/local: Operation not permitted
Failed during: /usr/bin/sudo /bin/mkdir /usr/local

The only feasible method I can think of is to do something like:

• Gain sudoer privileges
• `sudo nvram boot-args="rootless=0"
• Write a LaunchAgent, and restart. The LauchAgent will:
  • create /usr/local and set the proper permissions
  • resent nvram boot-args
  • delete itself
  • restart again

But this method is also the basic rubric for installing nigh-undeleteable malware.

Also the following files exist:

/System/Library/Sandbox/rootless.compat
/System/Library/Sandbox/rootless.conf
/usr/libexec/rootless-init

But these are completely undocumented and how they work is anyone's guess, I think.

(My personal opinion: I understand why Apple implemented this for iOS, but rootless for OS X is a pretty half-baked idea. As I mention above the fact that one can turn it off and on at will makes it a great way to install malware which effectively cannot be removed, particularly if one can manage to overwrite Apple's Installer certificate.)

[geoff-nixon]

As regards re-creating /usr/local with rootless enabled, this persists with beta 2; I've taken the liberty of opening rdar://21542005 at bugreport.apple.com.

Contents (In case someone wants to recreate on OpenRadar or elsewhere):

10.11: Rootless — Inability to re-create /usr/local if deleted.

Summary:
With the default configuration (rootless=1), it is possible for the root user to delete or move /usr/local, but it is not possible for the root user to re-create /usr/local. Per the WWDC '15 presentation "Security and Your Apps", /usr/local is to be "available to developers" (http://f.cl.ly/items/362w042M1V2C2b273313/Screen%20Shot%202015-06-12%20at%2012.57.46%20AM.png); this is not necessarily the case presently.

This is a particularly impediment to homebrew (which I imagine is largely why access to this directory was promised in the first place); please see:
#40837 (comment) and linked issues.

If my understanding is correct, 10.11 SIP only allows an installer package signed by the Apple Software Update CA (and other Apple CAs [?]) to modify a "rootless" protected directory. Therefore, presently there appears to be no means to re-create the directory without reinstalling Essentials.pkg in its entirety. It would be great if another means were added to rectify such a situation, such as:

• diskutil repairSomething /
• A properly signed package (contents: an empty /usr/local) were kept somewhere on the system
• Add some magic to mkdir.
• ?

Steps to Reproduce:

1. sudo rm -rf /usr/local.
2. sudo mkdir /usr/local.

Expected Results:
Ambiguous (?)

Actual Results:
mkdir: /usr/local: Operation not permitted
No (apparent) means to recreate without a complete reinstall.

Version:
10.11 beta 1; 10.11 beta 2

Notes:
I'm filing this under "Classification: Security" because this is a bug caused by a Security framework, not because it is a "security issue". I would still, respectfully, consider this a "serious bug".

Configuration:
Occurs on 10.11 beta 1 or beta 2.
Does not occur with "rootless=0" or on previous systems.

I'll report back if I get any updates.

[MikeMcQuaid]

Thanks @geoff-codes. I wouldn't worry too much; I'd be very surprised if the current behaviour survives to GA.

[geoff-nixon]

I wouldn't worry too much; I'd be very surprised if the current behaviour survives to GA.

Yeah I've just been trying out more of an "if you see something, say something" approach these days 📥.
Can't hurt, anyway. 😉

[MikeMcQuaid]

Yeah I've just been trying out more of an "if you see something, say something" approach these days .
Can't hurt, anyway.

Definitely. We always appreciate upstream bug reports about such things!

[DomT4]

Everything with a * next to it has write access with sudo. Everything on the list without that star is blocked to everyone:

                /System
*               /System/Library/Caches
booter          /System/Library/CoreServices
                /System/Library/CoreServices/RawCamera.bundle
*               /System/Library/Extensions
                /System/Library/Extensions/*
UpdateSettings  /System/Library/LaunchDaemons/com.apple.UpdateSettings.plist
*               /System/Library/Speech
*               /System/Library/User Template
                /bin
dyld            /private/var/db/dyld
                /sbin
                /usr
*               /usr/libexec/cups
*               /usr/local
*               /usr/share/man
# symlinks
                /etc
                /tmp
                /var

Source.

I'm not quite sure why /tmp is on the list; I can seem to write to that without sudo just fine. /etc is protected and can't write without sudo, as is /var.

There's also a small exemption list that permits certain non-Apple binaries in /usr/bin and /usr/sbin.

[chdiza]

If /etc can't be modified at all, how is one supposed to append a custom shell to /etc/shells? AFAIK the bash and zsh formulas will be dead without this ability.

[zmwangx]

@chdiza Without a working system to test, I would guess that

# symlinks
                /etc
                /tmp
                /var

in #40837 (comment) really means that the symlinks themselves can't be modified. The directories /private/etc, /private/tmp and /private/var should remain writable (it would be insane otherwise, especially for /private/tmp).

[DomT4]

Yes. You can still seem to write files to /etc, /tmp and /var. It hasn't been explained what Apple means by symlinks in that document.

[chriskrycho]

FWIW, sudo chown -R $USER /usr/local made brew work properly again for me.

[zmwangx]

living with the default permissions of /usr/local and accept that sudo is necessary to install stuff outside of a user's home directory;

Moot point. Homebrew trades sudoing over and over for sudoing once up front, during installation. It would be incredibly stupid if brew upgrade requires root permissions (after all these years), since I daresay a big chunk of users are constantly on the bleeding edge and upgrade daily, probably through automated jobs.

Rebooting a system twice from time to time.

Define "from time to time". You mean, after each system upgrade? Actually I don't understand "kept reverting to root ownership" mentioned above. The claim is not clear at all. Define "kept". Does that mean "after reboot"? Or "after toggling SIP"? At least I haven't seen that myself after a clean install of the final released build. Moreover, with SIP I can chmod on /usr/local without problem; no reboot required, let alone twice. Maybe I just haven't lived with it long enough, but I honestly don't think what hasn't happened today will magically happen tomorrow.

And isn't Homebrew mature enough to be a package manager for production environments?

No one stops you from running Homebrew from the root account "for production", as far as I could tell. The ownership will be root:admin rather than root:wheel, but I don't see how that's a big problem. Most things are not group writable anyway. The only caveat is that you have to keep using the root user to manage everything; not very different from apt.

How about having Homebrew installed in a user's home directory, but the Cellar in /usr/local?

Ridiculous.

[lifepillar]

a big chunk of users are constantly on the bleeding edge and upgrade daily, probably through automated jobs.

Such users are likely clever enough to fix their automated jobs once and for all. It surely would be less of a hassle than having such jobs periodically fail because permissions are reset.

Define "from time to time". You mean, after each system upgrade?

According to the link above, yes. But OS X 10.11 might check permissions at other times as well (a hint is that the Repair Permissions function in Disk Utility is not needed any longer). However, /usr/local may not be affected.

Moreover, with SIP I can chmod on /usr/local without problem; no reboot required, let alone twice.

Ah, a clean install already has /usr/local and you may change permissions on it. So, Recovery Mode is only needed if, for some reason, such directory does not exist. The question remains, whether such permissions are reverted by OS X or not, and when.

No one stops you from running Homebrew from the root account "for production", as far as I could tell.

As long as the feature is not officially supported (last time I checked it wasn't), no thanks.

How about having Homebrew installed in a user's home directory, but the Cellar in /usr/local?
Ridiculous.

Reasonable, if Homebrew is owned by me and the formulas are installed with administrator privileges. Anyway, If OS X lets you change the rights on /usr/local without interfering, I have no problem in keeping things as they are. But if the system reverts the changes I make then the message is clear: this is not the way you should do it, like it or not.

[DomT4]

Some replies which hopefully help handle various points raised before this discussion takes over the thread:

• At this time we aren't considering moving to another default prefix. /usr/local remains accessible to developers per Apple's own Keynote & everyone who writes into /usr/local and don't root "all the things" is going to deal with the same issues we are.
• I'm personally very strongly against reversing our sudo issue. You're either going to be using sudo for every brew command that writes into the prefix, or you use sudo to fix permissions every now and again. There's also the previously made argument of arbitrary code installing with full root access.
• What the situation is with SIP is unclear going forwards. Apple's public documentation and Keynote points on /usr/local are vague. It is implied that the permissions will be reset on updates (From 10.11 to 10.11.1 for example) but I haven't seen evidence of this yet. Likewise with Disk Utility resetting permissions on the directory. It's too early into the SIP timeline to make drastic decisions here.
• There are some 2231 core formulae with bottles, 1566 of which are relocatable. Moving prefix would involve rebuilding 665+ binary packages which could take weeks if nobody submits a PR & we don't do any core changes in that time, and a lot longer if anyone does.
• Every other tap in the Homebrew ecosystem would have to also migrate their bottles over if those bottles aren't relocatable.
• We could migrate people's data over to the new prefix but things would still break. Some things hardcode their prefix and moving that causes failure.
• A lot of automated scripts elsewhere would break. Bear in mind that Travis' OS X machines ship with Homebrew installed and using Homebrew for testing projects elsewhere is very common.

People can do what they like with their Homebrew installations, but we aren't going to rush a decision here and the plan for the foreseeable is to stay in /usr/local by default.

[zmwangx]

@lifepillar
To avoid taking over the thread, I won't respond to every point raised, but just want to point out an obvious flaw in your argument: at one point you are worried about having to boot into recovery "from time to time", but then you answered yourself:

Ah, a clean install already has /usr/local and you may change permissions on it. So, Recovery Mode is only needed if, for some reason, such directory does not exist. The question remains, whether such permissions are reverted by OS X or not, and when.

Okay, I'll just assume for now that OS X reverts /usr/local's permissions without notice from time to time. But what won't ever happen is /usr/local being deleted once it's already there (without action on the user's part anyway). So where does that booting into recovery from time to time coming from?

[lifepillar]

@zmwangx I have realized after your reply that Recovery Mode is necessary only under certain circumstances.

[Mikaela]

living with the default permissions of /usr/local and accept that sudo is necessary to install stuff outside of a user's home directory;

👍. I am breaking the guidelines by doing this, because I have multi-user (family) systems and it's possible for someone else to need to install something. Currently Homebrew is assuming all systems are only single user which can cause trouble when it's not true.

[DomT4]

brew should actually completely happily run under sudo if the executable is owned by root. We don't actively support the configuration, but we don't block it in the same way we do if the executable isn't owned by root.

[MStines007]

^^^ sudo brew update worked without issue, for me.

[cwonrails]

Speaking as someone who's been upgrading with every 10.11 beta and struggled endlessly with SIP, 👍 for @DomT4's comments above. For those seeking change, his conclusion warrants special attention:

People can do what they like with their Homebrew installations, but we aren't going to rush a decision here and the plan for the foreseeable is to stay in /usr/local by default.

As others have noted and many have experienced, Apple's implementation of and communication on SIP has been (at best) inconsistent. I can confirm that in my local environment (latest public beta) the permissions on /usr/local consistently reset of their own accord even when the user disables SIP and chowns the relevant directories. That does not, however, mean Homebrew should change default behaviors and environmental norms that users have internalized and relied upon for years. The onus is on Apple to align 10.11's real-world treatment of usr/local with the information presented at WWDC.

[ivan-leschinsky]

I found the answer to disable new security layer in the OS X 10.11.
In the recovery mode(reboot with Cmd+R) in the console:

csrutil disable

Then I can manage all system applications and files.
From here(last answer): https://apple.stackexchange.com/questions/101328/file-cant-be-moved-by-root-on-os-x/202969#202969?newreg=0b6a3e5858b5401bbe9e3040f9085f4c

[DomT4]

@ivan-leschinsky Please be aware Homebrew isn't recommending doing that for more than the length of time it takes to fix whatever permission issues you are seeing, unless you have other reasons to want full root access. We believe rootless is generally a good thing for the vast majority of users.

[ivan-leschinsky]

@DomT4 Got it. But disabling rootless doesn't helped me.

[DomT4]

@ivan-leschinsky What problems are you seeing?

[ivan-leschinsky]

@DomT4 I saw Operation not permitted error. But all is well now! Thanks 😄

[DomT4]

@ivan-leschinsky Glad to hear! Let us know if you hit any further issues :)

[apjanke]

Looks like there's a mongoclient update; see #44724.

[magic890]

Have you solved this problem?
I'm using Homebrew 0.9.5 (git revision 51a477; last commit 2015-08-03) and I'm still getting this error:

brew update
Error: The /usr/local directory is not writable.
Even if this directory was writable when you installed Homebrew, other
software may change permissions on this directory. Some versions of the
"InstantOn" component of Airfoil are known to do this.

You should probably change the ownership and permissions of /usr/local
back to your user account.
  sudo chown -R $(whoami):admin /usr/local

Running brew upgrade I was able to update some formulas.

[bfontaine]

@magic890 did you try running the suggested command?

[wspurgin]

System OpenSSL: Headers have seemingly been removed from the CLT and Xcode - #40519 (comment).

Haven't hit that issue just yet, but I ran across this interesting article that explains why they were removed

[magic890]

@bfontaine I ran brew doctor and tried to use sudo. Is that right?

[wspurgin]

@magic890 I think @bfontaine means have you used this command:
sudo chown -R $(whoami):admin /usr/local

I ran across the same issue you had, but the above command solved it for me.

[magic890]

Ok, now it is fixed. Thank you.

[MatthewHannigan]

You should use the -h option with chown, because you have to be careful in case the link points outside of /usr/local. And of course the link itself would not get changed, which might inhibit future homebrew operations.

I had a look at my /usr/local and there was a single link which linked outside;
/usr/local/Cellar/redo/0.11/lib/redo/sh -> /bin/sh

With El Capitan, chown'ing this results in Operation not permitted

In general, with almost any use of chown you want the -h flag. I would call it's normal behaviour a mis-design.

[DomT4]

Closing as most of the issues here are dealt with and fixed. The remaining ones are:

• xsp failed to build on 10.11 #44051 - Unrelated to OS X 10.11 specifically.
• openh264 failed to build on 10.11 #44060 - Is a nasm bug.

Thanks for coming along for the ride all. 10.11 was less a nightmare than 10.10, so that's something 😸.

[MikeMcQuaid]

Thanks for the great work here everyone (particularly @apjanke and @DomT4!)

[apjanke]

You're welcome! Glad this went well.