Unsigned kexts cannot be used on 10.10

[DomT4]

This is going to be a big pain in the behind for Homebrew, MacPorts, and compiling things from source generally.

Currently, from 10.10, the system no longer permits unsigned kexts to run, at all. The only public way to circumvent this 'security' measure at the moment is to disable all kext signing checks, which is a less than delightful solution.

The other way is limited to those with Apple development signing capabilities, which involves signing the kexts with your own certificates which will then enable them to run under Yosemite.

So far, this is already causing issues with tuntap and osxfuse [https://github.com/osxfuse/osxfuse/issues/150]. Right now, actually attempting to build osxfuse from source on 10.10 causes my entire system to panic out. I'm unsure on whether that is related or whether something in the latest DP upset the osxfuse build process.

Not really sure how Homebrew goes about dealing with this problem. Either we advise people to turn off kext signing checks, or we refuse software that utilises kernel extensions. Either solution kinda sucks.

[MikeMcQuaid]

Or, longer-term, perhaps we sign the kexts we provide in our bottles. Regardless the future of such things is distributing binaries (which I think is a good thing, actually).

[MikeMcQuaid]

Or, longer-term, perhaps we sign the kexts we provide in our bottles. Regardless the future of such things is distributing binaries (which I think is a good thing, actually).

[DomT4]

That could work too, although would that add onto the costs of running Homebrew in terms of having to obtain an OS X development certificate? I don't know what the current costs to donations ratio is, nor what financial burden those doing the maintaining take on, so I'll leave any comments on that side of things to those in the know.

The second part of your reply took me off-guard slightly. I'd always presumed Homebrew was partly brought into existence by the pro built-it-from-source attitude, and later became this fantastic hub of easily porting across software that provides no binary for the platform in question. I confess despite having hunted around the web a bit for a decent history of Homebrew I haven't really come across anything in-depth, so I may be guilty of viewing Homebrew through the rose-tinted glasses of my own love of source-code building.

[DomT4]

That could work too, although would that add onto the costs of running Homebrew in terms of having to obtain an OS X development certificate? I don't know what the current costs to donations ratio is, nor what financial burden those doing the maintaining take on, so I'll leave any comments on that side of things to those in the know.

The second part of your reply took me off-guard slightly. I'd always presumed Homebrew was partly brought into existence by the pro built-it-from-source attitude, and later became this fantastic hub of easily porting across software that provides no binary for the platform in question. I confess despite having hunted around the web a bit for a decent history of Homebrew I haven't really come across anything in-depth, so I may be guilty of viewing Homebrew through the rose-tinted glasses of my own love of source-code building.

[MikeMcQuaid]

Yeh, we might need to buy a certificate. We've got a bit of money stashed away though if we decide this is worthwhile.

I wrote the binary package/bottle support so I'm biased but I see build-from-source as being something that's useful for developers and maintainers to produce binary packages that are consumed by end-users. Even with the sandboxing we do the potential for things to go wrong are vastly higher with source packages, unfortunately.

[MikeMcQuaid]

Yeh, we might need to buy a certificate. We've got a bit of money stashed away though if we decide this is worthwhile.

I wrote the binary package/bottle support so I'm biased but I see build-from-source as being something that's useful for developers and maintainers to produce binary packages that are consumed by end-users. Even with the sandboxing we do the potential for things to go wrong are vastly higher with source packages, unfortunately.

[DomT4]

Alright. Let me know if that becomes more urgent and I'll happily cough up a little cash to aid with that.

Somewhat frustratingly there is nothing in the pre-release 10.10 documentation explaining their move to kill all unsigned kexts. The change happened in DP4/PB1, but the only reference to it so far is In Developer Preview 4, unsigned or improperly signed kexts will not be loaded. To use unsigned kexts during development, this strict check can be disabled by adding a **CENSORED** boot arg.. The only links on the development website currently, even on the pre-release stuff, links back to the 10.9 kext announcements.

(Unrelated note, 10.10 gets a Python version bump to Python 2.7.6.)

I certainly have no quibbles about source packages having the ability to go vastly more wrong than binary releases, that's something I see pretty often. I'm still a little rough around the edges in understanding the full Homebrew bottle system, but I understand the underlying process & intent behind it.

Part of my enjoyment in source packages is being able to set the initial configuration and then to have a very hands-on grasp of where things are going wrong, when/if they do. I often feel with binaries that I don't get that same level of understanding on all of the mechanisms in play, but because of that, perhaps I'm not the 'average consumer' in tech. I guess most people just want things to work. I kind of actively enjoy things not working and then figuring out how to make them work.

[DomT4]

Alright. Let me know if that becomes more urgent and I'll happily cough up a little cash to aid with that.

Somewhat frustratingly there is nothing in the pre-release 10.10 documentation explaining their move to kill all unsigned kexts. The change happened in DP4/PB1, but the only reference to it so far is In Developer Preview 4, unsigned or improperly signed kexts will not be loaded. To use unsigned kexts during development, this strict check can be disabled by adding a **CENSORED** boot arg.. The only links on the development website currently, even on the pre-release stuff, links back to the 10.9 kext announcements.

(Unrelated note, 10.10 gets a Python version bump to Python 2.7.6.)

I certainly have no quibbles about source packages having the ability to go vastly more wrong than binary releases, that's something I see pretty often. I'm still a little rough around the edges in understanding the full Homebrew bottle system, but I understand the underlying process & intent behind it.

Part of my enjoyment in source packages is being able to set the initial configuration and then to have a very hands-on grasp of where things are going wrong, when/if they do. I often feel with binaries that I don't get that same level of understanding on all of the mechanisms in play, but because of that, perhaps I'm not the 'average consumer' in tech. I guess most people just want things to work. I kind of actively enjoy things not working and then figuring out how to make them work.

[xiaket]

I bumped into this problem last Saturday. I tried to contact the author of tuntaposx, but got no reply. I found a signed tun/tap.ext in a beta bundle of tunnelblick. After I put signed externsions in /Library/Extensions and changed their permissions, tuntap worked as expected.

The problem is solved for this case. For those who have upgraded to Yosemite and do not want to downgrade, and who need to use openvpn and stuff like that, this is a temp workaround.

However, I do think we need to find a better way to distribute some developer signed binaries. I'm not familiar with the signing process, but I guess the certificate should not be included in the source code, is that right? If that's the case, I propose we add a sub command similar to cask, and install pre-built and signed binaries for end users, so they could do something like:

brew bins install tuntap

[xiaket]

I bumped into this problem last Saturday. I tried to contact the author of tuntaposx, but got no reply. I found a signed tun/tap.ext in a beta bundle of tunnelblick. After I put signed externsions in /Library/Extensions and changed their permissions, tuntap worked as expected.

The problem is solved for this case. For those who have upgraded to Yosemite and do not want to downgrade, and who need to use openvpn and stuff like that, this is a temp workaround.

However, I do think we need to find a better way to distribute some developer signed binaries. I'm not familiar with the signing process, but I guess the certificate should not be included in the source code, is that right? If that's the case, I propose we add a sub command similar to cask, and install pre-built and signed binaries for end users, so they could do something like:

brew bins install tuntap

[DomT4]

It's worth noting that right now, if you need to run unsigned kexts you can disable the signing check mechanism. It will be disabled for all kexts, which isn't the most comfortable or pleasant solution in the world, but we'll see where Apple takes this decision over the next few DPs, given the unsigned kext ban was only implemented in DP4.

You can turn off the kext checks by doing censored and rebooting. Be aware this will disable all kext signing checks.

[DomT4]

It's worth noting that right now, if you need to run unsigned kexts you can disable the signing check mechanism. It will be disabled for all kexts, which isn't the most comfortable or pleasant solution in the world, but we'll see where Apple takes this decision over the next few DPs, given the unsigned kext ban was only implemented in DP4.

You can turn off the kext checks by doing censored and rebooting. Be aware this will disable all kext signing checks.

[jokeyrhyme]

Do they need to be signed by an Apple-provided certificate? Is there a way for an individual user to trust a self-signed certificate of their choosing? Or is there a way for an individual user to get a free certificate from Apple?

[jokeyrhyme]

Do they need to be signed by an Apple-provided certificate? Is there a way for an individual user to trust a self-signed certificate of their choosing? Or is there a way for an individual user to get a free certificate from Apple?

[DomT4]

A) Right now, yes, they either need to be signed by Apple or signed by a valid Apple OS X Developers Certificate.

B) This isn't entirely clear just yet. Apple has issued no documentation on the kext signing changes from DP4, other than a note in the release notes highlighting that unsigned kexts would no longer load.

Right now you even have to justify each kext signing to Apple, before they'll allow that kext to be recognised as signed. You can sign kexts with an OS X developers certificate but unless Apple sticks that kext on their approved list it won't work on anyone but the developer's Mac. One would hope if they're going to tighten up the kext rules this much that process may become easier, but it's an unknown for now.

3. Nope. You absolutely must have a subscription to Apple's OS X Developer's Program before you can obtain such a certificate. I have a subscription to the iOS side of the dev program but even with that I can't access the kext signing request form.

[DomT4]

A) Right now, yes, they either need to be signed by Apple or signed by a valid Apple OS X Developers Certificate.

B) This isn't entirely clear just yet. Apple has issued no documentation on the kext signing changes from DP4, other than a note in the release notes highlighting that unsigned kexts would no longer load.

Right now you even have to justify each kext signing to Apple, before they'll allow that kext to be recognised as signed. You can sign kexts with an OS X developers certificate but unless Apple sticks that kext on their approved list it won't work on anyone but the developer's Mac. One would hope if they're going to tighten up the kext rules this much that process may become easier, but it's an unknown for now.

3. Nope. You absolutely must have a subscription to Apple's OS X Developer's Program before you can obtain such a certificate. I have a subscription to the iOS side of the dev program but even with that I can't access the kext signing request form.

[xiaket]

The author of tuntaposx replied my mail. He said he would obtain a certificate and provide a signed version of tuntaposx soon, though it would need sometime.

The question remains as to what could be done to the other kexts.

[xiaket]

The author of tuntaposx replied my mail. He said he would obtain a certificate and provide a signed version of tuntaposx soon, though it would need sometime.

The question remains as to what could be done to the other kexts.

[Noctem]

Interestingly, AppleKextExcludeList.kext still exists and its info.plist contains a new dictionary called OSKextSigExceptionHashList. But modifying it leads to this in the syslog:

Aug  2 02:04:40 Yosemite-VM com.apple.kextcache[97468]: AppleKextExcludeList.kext has invalid signature; Trust cache is disabled.
Aug  2 02:04:40 Yosemite-VM com.apple.kextcache[97468]: AppleKextExcludeList.kext has invalid signature; omitting.

and thus:

Aug  2 02:10:04 Yosemite-VM com.apple.kextd[19]: ERROR: invalid signature for foo.tap, will not load

It's preloaded with a lot though, including:

        <key>08a337bec50185b6afedbe6ad1e4abb1dfc70fbb</key>
        <string>org.fuse4x.kext.fuse4x  0.9.2</string>
        <key>4549c475ca3e138881124d13ce608c285cecc95a</key>
        <string>com.github.osxfuse.filesystems.osxfusefs    2.6.4</string>
        <key>008f7d23b07b898a0b1e06645d696bbb50fe8ac5</key>
        <string>net.tunnelblick.tun 1.0</string>
        <key>01ada26d5f2ea4318a0c1c3d0210f9066c4f1210</key>
        <string>foo.tun 1.0</string>
        <key>0507422ef41327ba4927a857f27444e6c2055270</key>
        <string>net.tunnelblick.tap 1.0</string>
        <key>05a6c717cbf50e17f6240d3a18fb3fdb70a21001</key>
        <string>com.pandapow.tun    1.0</string>
        <key>315ac89356ec7c6f6c204e93aeffb81e8c5a56db</key>
        <string>com.chungwasoft.Shimo.tun   1.1</string>
        <key>3cae18378274ad5ef283313c2b85922d1d3808df</key>
        <string>com.anchorfree.tun  1.0</string>
        <key>4086f44dd3fe966ff981205fb2b349cdd3fa055e</key>
        <string>net.tunnelblick.tap 1.0</string>
        <key>422ed4a139aea4f1a96012c4a878c2159416dd71</key>
        <string>me.faceless.tun 1.0</string>
        <key>58d8dd32a4f75f6abd09accda1c2c09dbe965e24</key>
        <string>com.frozenway.tun   1.0</string>
        <key>58d8dd32a4f75f6abd09accda1c2c09dbe965e24</key>
        <string>com.frozenway.tun   1.0</string>
        <key>e5d27ef0b936725dd59a1d0c98f888940fb6405b</key>
        <string>com.joshuawise.kexts.HoRNDIS    1.0.0d1</string>

It also has different versions for most of those, and even many listings of the same versions with different hashes. I couldn't find any for gpsim though.

Surprisingly, I did find a number of kexts that are used for Hackintoshes:

        <key>072e4303f63f6a6ca1c95586d1ff5f7ee5b11ab6</key>
        <string>org.netkas.FakeSMC  4.2.0</string>
        <key>776abf8cb3f21fdbc8b08e8854364e189e832260</key>
        <string>com.insanelymac.RealtekRTL8111  1.1.2</string>
        <key>e70e8203cc7536175c4bf796af980904afc62ce1</key>
        <string>com.tonymacx86.AHCI_3rdParty_SATA   1.0.0</string>
        <key>fa7afd75eeab54101a2fef9b1fc14394d17d7c04</key>
        <string>com.tonymacx86.JMicron36xSATA   0.8</string>
        <key>2a9eeb0770dae64732bc99cba196e04abbcb9bd9</key>
        <string>com.tonymacx86.ALC8xxHDA    3.0.1</string>
        <key>5710e33e6279136ffd00e8cc19d808ed45dd24a9</key>
        <string>com.Niresh12495.Hackintosh.AHCIPortInjector 1.0.0</string>
        <key>b90204a1b180844790019e0976b77cbf792f818e</key>
        <string>com.Niresh12495.Hackintosh.ATAPortInjector  1.0.0</string>
        <key>e8040befa56ae5b258dce573609b24ad93216344</key>
        <string>com.Niresh12495.Hackintosh.IOAHCIBlockStorageInjector   1.1.1</string>

So can this be taken as a tacit endorsment of Hackintoshes?

Anyways, in my opinion, this is a rather troubling move. Users should be able to install kernel extensions without a certificate without having to disable an important security measure for other kexts. Hopefully this isn't indicative of a continuing trend. My nightmare scenario is mandatory Gatekeeper for all executables, thus requiring people to jailbreak their Macs if they want to be free.

[Noctem]

Interestingly, AppleKextExcludeList.kext still exists and its info.plist contains a new dictionary called OSKextSigExceptionHashList. But modifying it leads to this in the syslog:

Aug  2 02:04:40 Yosemite-VM com.apple.kextcache[97468]: AppleKextExcludeList.kext has invalid signature; Trust cache is disabled.
Aug  2 02:04:40 Yosemite-VM com.apple.kextcache[97468]: AppleKextExcludeList.kext has invalid signature; omitting.

and thus:

Aug  2 02:10:04 Yosemite-VM com.apple.kextd[19]: ERROR: invalid signature for foo.tap, will not load

It's preloaded with a lot though, including:

        <key>08a337bec50185b6afedbe6ad1e4abb1dfc70fbb</key>
        <string>org.fuse4x.kext.fuse4x  0.9.2</string>
        <key>4549c475ca3e138881124d13ce608c285cecc95a</key>
        <string>com.github.osxfuse.filesystems.osxfusefs    2.6.4</string>
        <key>008f7d23b07b898a0b1e06645d696bbb50fe8ac5</key>
        <string>net.tunnelblick.tun 1.0</string>
        <key>01ada26d5f2ea4318a0c1c3d0210f9066c4f1210</key>
        <string>foo.tun 1.0</string>
        <key>0507422ef41327ba4927a857f27444e6c2055270</key>
        <string>net.tunnelblick.tap 1.0</string>
        <key>05a6c717cbf50e17f6240d3a18fb3fdb70a21001</key>
        <string>com.pandapow.tun    1.0</string>
        <key>315ac89356ec7c6f6c204e93aeffb81e8c5a56db</key>
        <string>com.chungwasoft.Shimo.tun   1.1</string>
        <key>3cae18378274ad5ef283313c2b85922d1d3808df</key>
        <string>com.anchorfree.tun  1.0</string>
        <key>4086f44dd3fe966ff981205fb2b349cdd3fa055e</key>
        <string>net.tunnelblick.tap 1.0</string>
        <key>422ed4a139aea4f1a96012c4a878c2159416dd71</key>
        <string>me.faceless.tun 1.0</string>
        <key>58d8dd32a4f75f6abd09accda1c2c09dbe965e24</key>
        <string>com.frozenway.tun   1.0</string>
        <key>58d8dd32a4f75f6abd09accda1c2c09dbe965e24</key>
        <string>com.frozenway.tun   1.0</string>
        <key>e5d27ef0b936725dd59a1d0c98f888940fb6405b</key>
        <string>com.joshuawise.kexts.HoRNDIS    1.0.0d1</string>

It also has different versions for most of those, and even many listings of the same versions with different hashes. I couldn't find any for gpsim though.

Surprisingly, I did find a number of kexts that are used for Hackintoshes:

        <key>072e4303f63f6a6ca1c95586d1ff5f7ee5b11ab6</key>
        <string>org.netkas.FakeSMC  4.2.0</string>
        <key>776abf8cb3f21fdbc8b08e8854364e189e832260</key>
        <string>com.insanelymac.RealtekRTL8111  1.1.2</string>
        <key>e70e8203cc7536175c4bf796af980904afc62ce1</key>
        <string>com.tonymacx86.AHCI_3rdParty_SATA   1.0.0</string>
        <key>fa7afd75eeab54101a2fef9b1fc14394d17d7c04</key>
        <string>com.tonymacx86.JMicron36xSATA   0.8</string>
        <key>2a9eeb0770dae64732bc99cba196e04abbcb9bd9</key>
        <string>com.tonymacx86.ALC8xxHDA    3.0.1</string>
        <key>5710e33e6279136ffd00e8cc19d808ed45dd24a9</key>
        <string>com.Niresh12495.Hackintosh.AHCIPortInjector 1.0.0</string>
        <key>b90204a1b180844790019e0976b77cbf792f818e</key>
        <string>com.Niresh12495.Hackintosh.ATAPortInjector  1.0.0</string>
        <key>e8040befa56ae5b258dce573609b24ad93216344</key>
        <string>com.Niresh12495.Hackintosh.IOAHCIBlockStorageInjector   1.1.1</string>

So can this be taken as a tacit endorsment of Hackintoshes?

Anyways, in my opinion, this is a rather troubling move. Users should be able to install kernel extensions without a certificate without having to disable an important security measure for other kexts. Hopefully this isn't indicative of a continuing trend. My nightmare scenario is mandatory Gatekeeper for all executables, thus requiring people to jailbreak their Macs if they want to be free.

[DomT4]

AppleKextExcludeList.kext is cryptographically verified I believe, so if the system detects unexpected changes to it, and consequently an unrecognized MD5/SHA1/SHA256/etc pops up Yosemite will just invalidate the file and ban any new additions from running. This is the same process that was started back with OS X Mavericks.

As for the current contents of the kext exception list, this is identical to the early Mavericks beta list. The early Mavericks beta kext exception list included every popular kext Apple knew to exist, and the list was whittled down over subsequent releases. They appear to be taking the same tact to Yosemite's list, with early exceptions for everything and then slimming the list down as devs have time to validly sign their kexts.

The Hackintosh kexts were there in the early Mavericks betas too, and then vanished, so I suspect that will happen this time as well. Don't expect Apple to ever get on board with Hackintoshes for the same reason they don't approve of jailbreaking, in that they see both as having a negative impact on system security & stability.

[DomT4]

AppleKextExcludeList.kext is cryptographically verified I believe, so if the system detects unexpected changes to it, and consequently an unrecognized MD5/SHA1/SHA256/etc pops up Yosemite will just invalidate the file and ban any new additions from running. This is the same process that was started back with OS X Mavericks.

As for the current contents of the kext exception list, this is identical to the early Mavericks beta list. The early Mavericks beta kext exception list included every popular kext Apple knew to exist, and the list was whittled down over subsequent releases. They appear to be taking the same tact to Yosemite's list, with early exceptions for everything and then slimming the list down as devs have time to validly sign their kexts.

The Hackintosh kexts were there in the early Mavericks betas too, and then vanished, so I suspect that will happen this time as well. Don't expect Apple to ever get on board with Hackintoshes for the same reason they don't approve of jailbreaking, in that they see both as having a negative impact on system security & stability.

[Noctem]

Indeed. I figured that's why it was complaining about an invalid signature in the log.

Interesting, I didn't know that was in the Mavericks betas. I don't actually expect them to endorse jailbreaking or Hackintoshes any time soon (if ever), which makes it all the more surprising that they are explicitly accommodating kexts that are only used on non-Apple hardware. I was especially surprised to see FakeSMC (a kext that masquerades as a real Mac's System Management Controller) on there.

Was kext signing also enforced like this on the Mavericks betas? Or was modifying the kext exclusion list allowed like it is in the 10.9.x releases?

I just noticed that the wording in the release notes doesn't explicitly state that this will be a permanent policy.

In Developer Preview 4, unsigned or improperly signed kexts will not be loaded

Do you suppose there's any chance that they will drop this restriction in the release version? Or should it just be assumed that they intend to keep new introductions to the developer previews? Perhaps they just want the kernel environment to to be clean in the previews for consistent testing and feedback.

[Noctem]

Indeed. I figured that's why it was complaining about an invalid signature in the log.

Interesting, I didn't know that was in the Mavericks betas. I don't actually expect them to endorse jailbreaking or Hackintoshes any time soon (if ever), which makes it all the more surprising that they are explicitly accommodating kexts that are only used on non-Apple hardware. I was especially surprised to see FakeSMC (a kext that masquerades as a real Mac's System Management Controller) on there.

Was kext signing also enforced like this on the Mavericks betas? Or was modifying the kext exclusion list allowed like it is in the 10.9.x releases?

I just noticed that the wording in the release notes doesn't explicitly state that this will be a permanent policy.

In Developer Preview 4, unsigned or improperly signed kexts will not be loaded

Do you suppose there's any chance that they will drop this restriction in the release version? Or should it just be assumed that they intend to keep new introductions to the developer previews? Perhaps they just want the kernel environment to to be clean in the previews for consistent testing and feedback.

[DomT4]

Mavericks introduced the idea of requiring kexts to be signed, but it never enforced it. You'd get a nice big Console warning if you ran unsigned kexts, but that'd be it, they'd still run. From Yosemite they've killed all unsigned kexts from running at all, unless you disable that security measure entirely.

AFAIK, You couldn't modify the kext exclusion list in the Mavericks betas either, although there wasn't especially a requirement to given that 10.9 never actually enforced the kext signing issue.

Somewhat frustratingly, from DP5 they've tightened up the overall code-signing rules even more, which isn't going to be a big issue for anything built locally from source but still, makes lives of devs a wee bit more troublesome.

As of DP5 you still need to sign your kexts for them to run. I'm probably going to open up an issue upstream about this to see if Apple is willing to write in rules that permit end users to allow specific unsigned kexts run rights, but I wouldn't be surprised if I get a 'Nope' on that.

If Apple wasn't expecting or intending to keep the unsigned kexts rule into the release versions I would have expected them to include it in the earlier DP releases. That they waited till DP4 to include it says to me they consider this idea ready for wider implementation. I'm going to ask upstream though, and see if I can get some clarity on the kext issue. Theoretically, any reply I get is covered under the NDA, but if I can share some more information without breaching that I'll do my best.

[DomT4]

Mavericks introduced the idea of requiring kexts to be signed, but it never enforced it. You'd get a nice big Console warning if you ran unsigned kexts, but that'd be it, they'd still run. From Yosemite they've killed all unsigned kexts from running at all, unless you disable that security measure entirely.

AFAIK, You couldn't modify the kext exclusion list in the Mavericks betas either, although there wasn't especially a requirement to given that 10.9 never actually enforced the kext signing issue.

Somewhat frustratingly, from DP5 they've tightened up the overall code-signing rules even more, which isn't going to be a big issue for anything built locally from source but still, makes lives of devs a wee bit more troublesome.

As of DP5 you still need to sign your kexts for them to run. I'm probably going to open up an issue upstream about this to see if Apple is willing to write in rules that permit end users to allow specific unsigned kexts run rights, but I wouldn't be surprised if I get a 'Nope' on that.

If Apple wasn't expecting or intending to keep the unsigned kexts rule into the release versions I would have expected them to include it in the earlier DP releases. That they waited till DP4 to include it says to me they consider this idea ready for wider implementation. I'm going to ask upstream though, and see if I can get some clarity on the kext issue. Theoretically, any reply I get is covered under the NDA, but if I can share some more information without breaching that I'll do my best.

[MentalPower]

FWIW, this is no different from the driver signing requirements on Windows 7+. No unsigned drivers are allowed to run unless you disable signature verification system-wide.

[MentalPower]

FWIW, this is no different from the driver signing requirements on Windows 7+. No unsigned drivers are allowed to run unless you disable signature verification system-wide.

[DomT4]

Most things ship with compiled binaries for Windows though. It is the prevalent OS. Due to OS X's UNIX heritage, quite a few popular utilities ship as source packages rather than compiled binaries (Especially true of things that were created for Linux & then ported across to OS X). I think it'll have a more noticeable impact here than it did on Windows, for better or worse.

[DomT4]

Most things ship with compiled binaries for Windows though. It is the prevalent OS. Due to OS X's UNIX heritage, quite a few popular utilities ship as source packages rather than compiled binaries (Especially true of things that were created for Linux & then ported across to OS X). I think it'll have a more noticeable impact here than it did on Windows, for better or worse.

[jacknagel]

Is it possible for us to sign kexts for bottles?

[jacknagel]

Is it possible for us to sign kexts for bottles?

[DomT4]

Theoretically, It's difficult, because Apple still mandates each kext certificate must be first approved by Apple. Theoretically, you can't just use one certificate to sign each kext, you must have a new one for each kext. Obtaining them is easy enough, but it'd put not insignificant burden on Homebrew to obtain a kext signing certificate from Apple for every kext we ship and then ensure only that kext is signed with only that certificate.

In practice? Not really sure yet. Nobody has tested the depth of this policy this early in. It may also be possible for Homebrew to obtain a wide exclusion permission from Apple for the kexts we ship, ie, get every com.mcxl.homebrew.examplekext onto this list which would permit them to run. Apple has been permissive about what goes onto that list so far, so option 2 may actually be easier than option 1.

[DomT4]

Theoretically, It's difficult, because Apple still mandates each kext certificate must be first approved by Apple. Theoretically, you can't just use one certificate to sign each kext, you must have a new one for each kext. Obtaining them is easy enough, but it'd put not insignificant burden on Homebrew to obtain a kext signing certificate from Apple for every kext we ship and then ensure only that kext is signed with only that certificate.

In practice? Not really sure yet. Nobody has tested the depth of this policy this early in. It may also be possible for Homebrew to obtain a wide exclusion permission from Apple for the kexts we ship, ie, get every com.mcxl.homebrew.examplekext onto this list which would permit them to run. Apple has been permissive about what goes onto that list so far, so option 2 may actually be easier than option 1.

[MikeMcQuaid]

So basically: not really. I think it's better for these things to be distributed as binaries anyway, personally.

[MikeMcQuaid]

So basically: not really. I think it's better for these things to be distributed as binaries anyway, personally.

[DomT4]

Yeah, I'm not a huge fan of binaries, but when it comes to the new kext permissions we're probably better off and making life easier for folks to ship the upstream signed binaries or merely point people to those instead of trying to kext sign everything in Homebrew.

[DomT4]

Yeah, I'm not a huge fan of binaries, but when it comes to the new kext permissions we're probably better off and making life easier for folks to ship the upstream signed binaries or merely point people to those instead of trying to kext sign everything in Homebrew.

[iferguson90]

Right now you even have to justify each kext signing to Apple, before they'll allow that kext to be recognised as signed. You can sign kexts with an OS X developers certificate but unless Apple sticks that kext on their approved list it won't work on anyone but the developer's Mac. One would hope if they're going to tighten up the kext rules this much that process may become easier, but it's an unknown for now.

To clarify, with a standard, Apple-issued OS X Dev Program Certificate, I can sign a .kext and have it run on my system, but not on someone else's system?

And a .kext signed by a self-issued code-signing certificate (generated through Keychain Access > Certificate Assistant) will not work under any circumstances?

(If I understand the codesigning documentation correctly, it seems like standard .apps and binaries can be signed with a self-issued certificate so long as the certificate is marked as trusted in Keychain Access. If this policy doesn't extend to .kexts then this is an incredibly frustrating and worrying change.)

[iferguson90]

Right now you even have to justify each kext signing to Apple, before they'll allow that kext to be recognised as signed. You can sign kexts with an OS X developers certificate but unless Apple sticks that kext on their approved list it won't work on anyone but the developer's Mac. One would hope if they're going to tighten up the kext rules this much that process may become easier, but it's an unknown for now.

To clarify, with a standard, Apple-issued OS X Dev Program Certificate, I can sign a .kext and have it run on my system, but not on someone else's system?

And a .kext signed by a self-issued code-signing certificate (generated through Keychain Access > Certificate Assistant) will not work under any circumstances?

(If I understand the codesigning documentation correctly, it seems like standard .apps and binaries can be signed with a self-issued certificate so long as the certificate is marked as trusted in Keychain Access. If this policy doesn't extend to .kexts then this is an incredibly frustrating and worrying change.)

[sormy]

Also, all homebrew kext autoloading relying on /Library/StartupItems will not work anymore on Yosemite. Need to rewrite to use /Library/LaunchDaemons.

[sormy]

Also, all homebrew kext autoloading relying on /Library/StartupItems will not work anymore on Yosemite. Need to rewrite to use /Library/LaunchDaemons.

[bh88]

For those who have a Apple Dev account and want to know more about the changes causing this or how to sign your own kext(need mac dev account) here is the presentation from 2013 WWDC https://developer.apple.com/videos/wwdc/2013/?id=707

[bh88]

For those who have a Apple Dev account and want to know more about the changes causing this or how to sign your own kext(need mac dev account) here is the presentation from 2013 WWDC https://developer.apple.com/videos/wwdc/2013/?id=707

[DomT4]

To clarify, with a standard, Apple-issued OS X Dev Program Certificate, I can sign a .kext and have it run on my system, but not on someone else's system?

And a .kext signed by a self-issued code-signing certificate (generated through Keychain Access > Certificate Assistant) will not work under any circumstances?

To number 1, yes, if you are part of the OS X dev program you can still sign your own kexts and they should run. But if you want it to run on someone else's system you'll need to obtain a kext signing certificate specifically for that kext from Apple.

This requirement was actually implemented last year, but they decided not to enforce the unsigned kext ban on Mavericks and consequently most people didn't bother to issue signed kexts as the worst that would happen is that the syslog would contain a warning about using an unsigned kext but consequently most users never ever saw that flagged up.

To number 2, I haven't actually seen any guidance on that yet, but yes, that is my understanding thus far.

Also, all homebrew kext autoloading relying on /Library/StartupItems will not work anymore on Yosemite. Need to rewrite to use /Library/LaunchDaemons.

Yes, StartupItems has been depreciated formally now.

[DomT4]

To clarify, with a standard, Apple-issued OS X Dev Program Certificate, I can sign a .kext and have it run on my system, but not on someone else's system?

And a .kext signed by a self-issued code-signing certificate (generated through Keychain Access > Certificate Assistant) will not work under any circumstances?

To number 1, yes, if you are part of the OS X dev program you can still sign your own kexts and they should run. But if you want it to run on someone else's system you'll need to obtain a kext signing certificate specifically for that kext from Apple.

This requirement was actually implemented last year, but they decided not to enforce the unsigned kext ban on Mavericks and consequently most people didn't bother to issue signed kexts as the worst that would happen is that the syslog would contain a warning about using an unsigned kext but consequently most users never ever saw that flagged up.

To number 2, I haven't actually seen any guidance on that yet, but yes, that is my understanding thus far.

Also, all homebrew kext autoloading relying on /Library/StartupItems will not work anymore on Yosemite. Need to rewrite to use /Library/LaunchDaemons.

Yes, StartupItems has been depreciated formally now.

[netheril96]

OSX Fuse developers say that their binary distribution is signed, so can be used in Yosemite without modifications. Maybe we could add an option to build sshfs, ntfs-3g and others against a preinstalled osxfuse instead of homebrew one?

[netheril96]

OSX Fuse developers say that their binary distribution is signed, so can be used in Yosemite without modifications. Maybe we could add an option to build sshfs, ntfs-3g and others against a preinstalled osxfuse instead of homebrew one?

[DomT4]

Maybe we could add an option to build sshfs, ntfs-3g and others against a preinstalled osxfuse instead of homebrew one?

This happened a few weeks ago :). You can already do this inside Homebrew. It's why the osxfuse dependency everywhere is now :osxfuse rather than "osxfuse", because we support the binary installation of it as well as the source package.

[DomT4]

Maybe we could add an option to build sshfs, ntfs-3g and others against a preinstalled osxfuse instead of homebrew one?

This happened a few weeks ago :). You can already do this inside Homebrew. It's why the osxfuse dependency everywhere is now :osxfuse rather than "osxfuse", because we support the binary installation of it as well as the source package.

[MikeMcQuaid]

Do SSHFS and friends not rely on any kexts of their own? If so, that might be the way forward (or even installing their binary in the Homebrew package). I think it might be worth encouraging upstreams to release binaries and/or pushing this to homebrew-cask, though; I don't think the user experience of telling a user to go outside Homebrew and install binaries is a pleasant one.

[MikeMcQuaid]

Do SSHFS and friends not rely on any kexts of their own? If so, that might be the way forward (or even installing their binary in the Homebrew package). I think it might be worth encouraging upstreams to release binaries and/or pushing this to homebrew-cask, though; I don't think the user experience of telling a user to go outside Homebrew and install binaries is a pleasant one.

[MikeMcQuaid]

Also: I'll continue censoring instructions on how to configure your system to accept unsigned kexts. It's a security feature, I think it's a good one and I don't want it discussed here (you can Google if you want to find out). I'll continue censoring and eventually will lock this thread if it keeps being posted (sorry).

[MikeMcQuaid]

Also: I'll continue censoring instructions on how to configure your system to accept unsigned kexts. It's a security feature, I think it's a good one and I don't want it discussed here (you can Google if you want to find out). I'll continue censoring and eventually will lock this thread if it keeps being posted (sorry).

[DomT4]

Homebrew-cask seem to be able to ship .pkg files, so despite my own personal grudge against binaries I'd be content to nudge people in that direction so there's a consistent install method & preference that at least we have a better grip on the variables of.

At least for SSHFS it looks like there's no extra kexts shipped on that:

[DomT4]

Homebrew-cask seem to be able to ship .pkg files, so despite my own personal grudge against binaries I'd be content to nudge people in that direction so there's a consistent install method & preference that at least we have a better grip on the variables of.

At least for SSHFS it looks like there's no extra kexts shipped on that:

[netheril96]

@MikeMcQuaid

Only osx-fuse has kernel extension. The modules that depends on it are all in userspace, as the name FUSE implies (Filesystem in Userspace). So currently I install osx-fuse with the signed binary from its homepage, and compile the rest with homebrew.

@DomT4

It's why the osxfuse dependency everywhere is now :osxfuse rather than "osxfuse", because we support the binary installation of it as well as the source package.

What's the difference?

I just removed the dependency of osxfuse with brew edit then brew install. Does this option intelligently determine whether one has installed osxfuse outside homebrew?

[netheril96]

@MikeMcQuaid

Only osx-fuse has kernel extension. The modules that depends on it are all in userspace, as the name FUSE implies (Filesystem in Userspace). So currently I install osx-fuse with the signed binary from its homepage, and compile the rest with homebrew.

@DomT4

It's why the osxfuse dependency everywhere is now :osxfuse rather than "osxfuse", because we support the binary installation of it as well as the source package.

What's the difference?

I just removed the dependency of osxfuse with brew edit then brew install. Does this option intelligently determine whether one has installed osxfuse outside homebrew?

[DomT4]

@netheril96 Generally, where you see the : dependency prefix instead of the double quotes it means we support someone using either the system-shipped version or a binary.

No need to remove the dependency these days. Presuming you've ran a brew update && brew upgrade at some point in the last 5 weeks or so it should automatically notice that you've got the binary installed, yes.

[DomT4]

@netheril96 Generally, where you see the : dependency prefix instead of the double quotes it means we support someone using either the system-shipped version or a binary.

No need to remove the dependency these days. Presuming you've ran a brew update && brew upgrade at some point in the last 5 weeks or so it should automatically notice that you've got the binary installed, yes.

[MikeMcQuaid]

Does this option intelligently determine whether one has installed osxfuse outside homebrew?

yes

[MikeMcQuaid]

Does this option intelligently determine whether one has installed osxfuse outside homebrew?

yes

[orand]

Mike, I already read, understood, and agreed with that before posting my comment. I would appreciate it if you had actually read and comprehended my post before deleting it. If you had, you would have realized I am 100% in agreement with you and was seeking more detail from the one person who seems to have a solution involving signed kexts. You know, the good kind that you're promoting. Please undelete my post. It contains the steps I took to try to get signed kexts working and may be valuable to others. Thanks.

[orand]

Mike, I already read, understood, and agreed with that before posting my comment. I would appreciate it if you had actually read and comprehended my post before deleting it. If you had, you would have realized I am 100% in agreement with you and was seeking more detail from the one person who seems to have a solution involving signed kexts. You know, the good kind that you're promoting. Please undelete my post. It contains the steps I took to try to get signed kexts working and may be valuable to others. Thanks.

[trisweb]

Can someone kindly give a concise, up-to-date sentence or two on how to get fuse4x working nicely with Homebrew on Yosemite? Is there a place that sort of documentation should exist?

[trisweb]

Can someone kindly give a concise, up-to-date sentence or two on how to get fuse4x working nicely with Homebrew on Yosemite? Is there a place that sort of documentation should exist?

[DomT4]

Sure. Get upstream to release a signed binary which contains signed kexts. That's what it'll take on Yosemite. You'd probably be better using osxfuse because they do have an upstream binary with a signed kext available already.

There is another route around, but it involves scooping up OS X security and throwing it out of the window whilst laughing gleefully. You can find that method through Google/DuckDuckGo/Bing/Etc if desired, but I genuinely wouldn't recommend it.

[DomT4]

Sure. Get upstream to release a signed binary which contains signed kexts. That's what it'll take on Yosemite. You'd probably be better using osxfuse because they do have an upstream binary with a signed kext available already.

There is another route around, but it involves scooping up OS X security and throwing it out of the window whilst laughing gleefully. You can find that method through Google/DuckDuckGo/Bing/Etc if desired, but I genuinely wouldn't recommend it.

[trisweb]

Thank you! For others, I found the package install here: https://github.com/fuse4x/fuse4x/downloads

This appears to work fine with homebrew packages which depend on it.

[trisweb]

Thank you! For others, I found the package install here: https://github.com/fuse4x/fuse4x/downloads

This appears to work fine with homebrew packages which depend on it.

[DomT4]

There's no guarantee that'll work for long though. Both that package and the kext within are completely unsigned. The only reason it works on Yosemite at the moment is that Apple have tagged it into their kextexclusionlist but they can remove it at any point they wish.

[DomT4]

There's no guarantee that'll work for long though. Both that package and the kext within are completely unsigned. The only reason it works on Yosemite at the moment is that Apple have tagged it into their kextexclusionlist but they can remove it at any point they wish.

[DomT4]

Your comment above will be censored out as soon as Mike notices it. See his comment 7 days ago. By all means, Google/DuckDuckGo/Bing/etc it and find the answer, but certainly Mike and very possibly some of the other maintainers frown on making it easy for others to circumvent Apple's security features.

[DomT4]

Your comment above will be censored out as soon as Mike notices it. See his comment 7 days ago. By all means, Google/DuckDuckGo/Bing/etc it and find the answer, but certainly Mike and very possibly some of the other maintainers frown on making it easy for others to circumvent Apple's security features.

[alseambusher]

@DomT4 my apologies. However I think whether one wants to circumvent Apple's security features or not should be left to users themselves. In a developer's machine doing this is not really a bad thing.

[alseambusher]

@DomT4 my apologies. However I think whether one wants to circumvent Apple's security features or not should be left to users themselves. In a developer's machine doing this is not really a bad thing.

[DomT4]

No need to apologise to me. I was just pointing it out. Homebrew isn't blocking users from tweaking their machines to their heart's content, Homebrew seemingly just doesn't want to facilitate that directly because if it does and everything goes to hell and problems arise 1) It's crappy for the end-user. 2) The finger and demand to fix things gets pointed sharply at Homebrew and its maintainers.

There's nothing at all stopping people from using their search engine to find the answer. There's nothing in the Homebrew code that prohibits the modification itself. Homebrew just won't facilitate that security circumvention. I can't and don't speak for the maintainers here, but IMO signed kext checks are a valuable and welcome thing. Yes, they can be frustrating, yes they annoy me, but I also appreciate no longer is it possible for any random unsigned kernel extension to hook into my system and essentially have free reign. The current exception list is huge, and Apple have been swift in responding to kext certificate requests, and consequently we already formally support osxfuse on 10.10 which is a huge thing.

To be honest, everyone had a year's warning on this. Mavericks introduced kext checks, with the intention of making those strict, but for whatever reason Apple held off on implementing fully that policy for Yosemite, but really, Apple made it clear where things were going in Mavericks. Sadly it went largely unnoticed and un-acted upon, and now Yosemite has landed everyone is rushing to sign their kexts or lose software compatibility.

This whole thing is a bit bleh. There wasn't enough communication around it, by and large, but it is here now and being enforced and long-term will be a good thing IMO.

Anyway, that's my ramble on the subject. I'll shut up and go away again now 😀.

[DomT4]

No need to apologise to me. I was just pointing it out. Homebrew isn't blocking users from tweaking their machines to their heart's content, Homebrew seemingly just doesn't want to facilitate that directly because if it does and everything goes to hell and problems arise 1) It's crappy for the end-user. 2) The finger and demand to fix things gets pointed sharply at Homebrew and its maintainers.

There's nothing at all stopping people from using their search engine to find the answer. There's nothing in the Homebrew code that prohibits the modification itself. Homebrew just won't facilitate that security circumvention. I can't and don't speak for the maintainers here, but IMO signed kext checks are a valuable and welcome thing. Yes, they can be frustrating, yes they annoy me, but I also appreciate no longer is it possible for any random unsigned kernel extension to hook into my system and essentially have free reign. The current exception list is huge, and Apple have been swift in responding to kext certificate requests, and consequently we already formally support osxfuse on 10.10 which is a huge thing.

To be honest, everyone had a year's warning on this. Mavericks introduced kext checks, with the intention of making those strict, but for whatever reason Apple held off on implementing fully that policy for Yosemite, but really, Apple made it clear where things were going in Mavericks. Sadly it went largely unnoticed and un-acted upon, and now Yosemite has landed everyone is rushing to sign their kexts or lose software compatibility.

This whole thing is a bit bleh. There wasn't enough communication around it, by and large, but it is here now and being enforced and long-term will be a good thing IMO.

Anyway, that's my ramble on the subject. I'll shut up and go away again now 😀.

[netheril96]

@DomT4

but IMO signed kext checks are a valuable and welcome thing. Yes, they can be frustrating, yes they annoy me, but I also appreciate no longer is it possible for any random unsigned kernel extension to hook into my system and essentially have free reign.

But I'd like to sign the kernel extensions I compile myself without paying again to Apple when I have already bought their machine. Irrelevant though, since this is not Apple forum.

and consequently we already formally support osxfuse on 10.10 which is a huge thing.

Did I miss something?

[netheril96]

@DomT4

but IMO signed kext checks are a valuable and welcome thing. Yes, they can be frustrating, yes they annoy me, but I also appreciate no longer is it possible for any random unsigned kernel extension to hook into my system and essentially have free reign.

But I'd like to sign the kernel extensions I compile myself without paying again to Apple when I have already bought their machine. Irrelevant though, since this is not Apple forum.

and consequently we already formally support osxfuse on 10.10 which is a huge thing.

Did I miss something?

[MikeMcQuaid]

@DomT4 my apologies. However I think whether one wants to circumvent Apple's security features or not should be left to users themselves. In a developer's machine doing this is not really a bad thing.

So, there's two reasons Apple could have added this feature to 10.10:

1. They are greedy capitalists who want to squeeze every last drop of money out of users and developers
2. Unsigned kexts have previously been used to attack OSX users' systems

I think it's 2) and as a result I will be continuing to censor people who are showing or encouraging others to disable this security feature. I don't want Homebrew's popularity to be something that compromises users' systems. If you don't like that: please go write about it on your own blog rather than here.

[MikeMcQuaid]

@DomT4 my apologies. However I think whether one wants to circumvent Apple's security features or not should be left to users themselves. In a developer's machine doing this is not really a bad thing.

So, there's two reasons Apple could have added this feature to 10.10:

1. They are greedy capitalists who want to squeeze every last drop of money out of users and developers
2. Unsigned kexts have previously been used to attack OSX users' systems

I think it's 2) and as a result I will be continuing to censor people who are showing or encouraging others to disable this security feature. I don't want Homebrew's popularity to be something that compromises users' systems. If you don't like that: please go write about it on your own blog rather than here.

[MikeMcQuaid]

Finally, if people are unable to stop posting links/instructions for this in this thread I'm going to just lock the thread and close it.

[MikeMcQuaid]

Finally, if people are unable to stop posting links/instructions for this in this thread I'm going to just lock the thread and close it.

[DomT4]

But I'd like to sign the kernel extensions I compile myself without paying again to Apple when I have already bought their machine. Irrelevant though, since this is not Apple forum.

That's an understandable desire, but as you said, an upstream issue. I have actually opened a request upstream asking that Apple permit users to disable kext checks on single specific kexts through the command-line, to permit easier development and debugging, but whether Apple ever act on that or not is entirely down to them.

Did I miss something?

Osxfuse very quickly issued a signed binary containing a signed kext, and consequently Homebrew switched to supporting both the signed binary and kext for everyone, including Yosemite and the source package for <Yosemite. Where things previously relied on the source package you can now use the upstream binary.

[DomT4]

But I'd like to sign the kernel extensions I compile myself without paying again to Apple when I have already bought their machine. Irrelevant though, since this is not Apple forum.

That's an understandable desire, but as you said, an upstream issue. I have actually opened a request upstream asking that Apple permit users to disable kext checks on single specific kexts through the command-line, to permit easier development and debugging, but whether Apple ever act on that or not is entirely down to them.

Did I miss something?

Osxfuse very quickly issued a signed binary containing a signed kext, and consequently Homebrew switched to supporting both the signed binary and kext for everyone, including Yosemite and the source package for <Yosemite. Where things previously relied on the source package you can now use the upstream binary.

[marblenix]

Instead of creating a second issue I'll post this update here since @DomT4 mentioned tuntap by name.

About 15 hours ago a new signed version of tuntap got uploaded.

Relevant mailing list post http://sourceforge.net/p/tuntaposx/mailman/message/33000809/

Maybe people will want to wait until the author releases the next major version, but as of now I'm up and running with the tuntap_20141104.tar.gz binaries.

I did however have to remove all previous versions of tuntap and tunnelblick's kexts with kextunload and removing the kext folders outright (including the scripts in /Library/StartupItems).

[marblenix]

Instead of creating a second issue I'll post this update here since @DomT4 mentioned tuntap by name.

About 15 hours ago a new signed version of tuntap got uploaded.

Relevant mailing list post http://sourceforge.net/p/tuntaposx/mailman/message/33000809/

Maybe people will want to wait until the author releases the next major version, but as of now I'm up and running with the tuntap_20141104.tar.gz binaries.

I did however have to remove all previous versions of tuntap and tunnelblick's kexts with kextunload and removing the kext folders outright (including the scripts in /Library/StartupItems).

[DomT4]

See #33894 for movement on tuntap.

Those kexts are considered released, but Mattias is waiting for a couple days to see if anyone flags up any issues before pushing them front and centre on the website. I unloaded and reloaded them into the kext bank about 25 times last time and didn't hit any issues at all, nothing in the console, no errors, no problems on reboot, so it looks like Mattias has done a great job here.

Having to remove all traces of the unsigned kexts is expected. Hopefully people will do that and then update to the signed binary. We'll be supporting those signed kexts ASAP, and re-enabling functionality of the things that depend on tuntap for Yosemite.

[DomT4]

See #33894 for movement on tuntap.

Those kexts are considered released, but Mattias is waiting for a couple days to see if anyone flags up any issues before pushing them front and centre on the website. I unloaded and reloaded them into the kext bank about 25 times last time and didn't hit any issues at all, nothing in the console, no errors, no problems on reboot, so it looks like Mattias has done a great job here.

Having to remove all traces of the unsigned kexts is expected. Hopefully people will do that and then update to the signed binary. We'll be supporting those signed kexts ASAP, and re-enabling functionality of the things that depend on tuntap for Yosemite.

[mouse07410]

But I'd like to sign the kernel extensions I compile myself without paying again to Apple when I have already bought their machine. Irrelevant though, since this is not Apple forum.

That's an understandable desire, but as you said, an upstream issue. I have actually opened a request upstream asking that Apple permit users to disable kext checks on single specific kexts through the command-line, to permit easier development and debugging, but whether Apple ever act on that or not is entirely down to them.

I have a CA, and code-signing certs. I've been able to successfully sign code and set up policies that would allow code signed by the given certs to be installed and executed.

However, that does not seem to apply to kext (kernel extensions). Despite the kext signatures being accepted and validated by codesign and spctl, kextutil insists that the signature is invalid. Here's the output I'm getting:

$ codesign --verify -vvvv /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: valid on disk
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: satisfies its Designated Requirement

$ spctl -a -vvv -t exec /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: accepted
source=XXXXXCode
origin=XXXXXCoder
$ spctl -a -vvv -t install /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: accepted
source=XXXXXInstall
origin=XXXXXCoder

$ kextutil -tn /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
Diagnostics for /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext:
Code Signing Failure: code signature is invalid
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext appears to be loadable (including linkage for on-disk libraries).

On Mavericks this kext loads with a warning message, on Yosemite it will not.

I noticed on Stackoverflow that the cert must have the following extension: ( 1.2.840.113635.100.6.1.18 ) to designate it as kext-signing certificate. Mine does not have it.

How do I add this extension (preferably within Keychain Certificate Assist, though an OpenSSL-based solution would be fine too), short of paying Apple annual "usage fee" of $100?

[mouse07410]

But I'd like to sign the kernel extensions I compile myself without paying again to Apple when I have already bought their machine. Irrelevant though, since this is not Apple forum.

That's an understandable desire, but as you said, an upstream issue. I have actually opened a request upstream asking that Apple permit users to disable kext checks on single specific kexts through the command-line, to permit easier development and debugging, but whether Apple ever act on that or not is entirely down to them.

I have a CA, and code-signing certs. I've been able to successfully sign code and set up policies that would allow code signed by the given certs to be installed and executed.

However, that does not seem to apply to kext (kernel extensions). Despite the kext signatures being accepted and validated by codesign and spctl, kextutil insists that the signature is invalid. Here's the output I'm getting:

$ codesign --verify -vvvv /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: valid on disk
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: satisfies its Designated Requirement

$ spctl -a -vvv -t exec /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: accepted
source=XXXXXCode
origin=XXXXXCoder
$ spctl -a -vvv -t install /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: accepted
source=XXXXXInstall
origin=XXXXXCoder

$ kextutil -tn /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext
Diagnostics for /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext:
Code Signing Failure: code signature is invalid
/opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext appears to be loadable (including linkage for on-disk libraries).

On Mavericks this kext loads with a warning message, on Yosemite it will not.

I noticed on Stackoverflow that the cert must have the following extension: ( 1.2.840.113635.100.6.1.18 ) to designate it as kext-signing certificate. Mine does not have it.

How do I add this extension (preferably within Keychain Certificate Assist, though an OpenSSL-based solution would be fine too), short of paying Apple annual "usage fee" of $100?

[MikeMcQuaid]

How do I add this extension (preferably within Keychain Certificate Assist, though an OpenSSL-based solution would be fine too), short of paying Apple annual "usage fee" of $100?

I'd suggest you take this to StackOverflow instead.

[MikeMcQuaid]

How do I add this extension (preferably within Keychain Certificate Assist, though an OpenSSL-based solution would be fine too), short of paying Apple annual "usage fee" of $100?

I'd suggest you take this to StackOverflow instead.

[mouse07410]

Just did. :-)

Would you like me to delete my post from here? I think this kext thing impacts home-brew, macports, and probably others as well.

[mouse07410]

Just did. :-)

Would you like me to delete my post from here? I think this kext thing impacts home-brew, macports, and probably others as well.

[DomT4]

I found your post a useful technical insight, so I'd be happy to see it stick around if Mike has no objections.

The kext thing indeed impacts MacPorts, Fink, and anything else that ships with unsigned kexts as well. I'm not sure how/if MacPorts and Fink are working around the issue at this point.

[DomT4]

I found your post a useful technical insight, so I'd be happy to see it stick around if Mike has no objections.

The kext thing indeed impacts MacPorts, Fink, and anything else that ships with unsigned kexts as well. I'm not sure how/if MacPorts and Fink are working around the issue at this point.

[mouse07410]

@DomT4, thank you!

I see only three options:

1. For distributions like MacPorts, Fink, Homebrew to distribute kext-related stuff in binary only, pre-signed with the appropriate key/cert. This is probably inevitable, as far as I can see, regardless of everything else.
2. For everybody who wants to run non-Apple kext, fork out $100 annually to Apple. Needless to say, this option does not rock.
3. Finally, figure out what it takes to generate a cert with the extension "( 1.2.840.113635.100.6.1.18 )" added/listed, and see if it (together with some other mucking, which I've already figured out) would solve the problem. This is the path I'm going to pursue, and would appreciate help with that listed extension.

[mouse07410]

@DomT4, thank you!

I see only three options:

1. For distributions like MacPorts, Fink, Homebrew to distribute kext-related stuff in binary only, pre-signed with the appropriate key/cert. This is probably inevitable, as far as I can see, regardless of everything else.
2. For everybody who wants to run non-Apple kext, fork out $100 annually to Apple. Needless to say, this option does not rock.
3. Finally, figure out what it takes to generate a cert with the extension "( 1.2.840.113635.100.6.1.18 )" added/listed, and see if it (together with some other mucking, which I've already figured out) would solve the problem. This is the path I'm going to pursue, and would appreciate help with that listed extension.

[DomT4]

For distributions like MacPorts, Fink, Homebrew to distribute kext-related stuff in binary only, pre-signed with the appropriate key/cert. This is probably inevitable, as far as I can see, regardless of everything else.

Long term, for security-reasons and Yosemite-enforced-reasons, always shipping signed kexts where available will probably become the default over source packages. Kexts do wield an enormous amount of power, and mandating their signing is a more secure (if irritating) route to go down.

[DomT4]

For distributions like MacPorts, Fink, Homebrew to distribute kext-related stuff in binary only, pre-signed with the appropriate key/cert. This is probably inevitable, as far as I can see, regardless of everything else.

Long term, for security-reasons and Yosemite-enforced-reasons, always shipping signed kexts where available will probably become the default over source packages. Kexts do wield an enormous amount of power, and mandating their signing is a more secure (if irritating) route to go down.

[mouse07410]

Yes I concur - for security reasons kext should be signed. So I didn't even list the 4th option - allow installation of unsigned extensions.

But I really hate seeing computer owners prevented from adding their own extensions to their own kernels... Which is why I really want to find an answer to (3) above.

[mouse07410]

Yes I concur - for security reasons kext should be signed. So I didn't even list the 4th option - allow installation of unsigned extensions.

But I really hate seeing computer owners prevented from adding their own extensions to their own kernels... Which is why I really want to find an answer to (3) above.

[DomT4]

Yeah. I did put in a request to Apple a couple of months back along the lines of "Instead of either permitting no unsigned kexts or all unsigned kexts could we possibly permit a specific unsigned kext from the command line?" but they haven't got back to me yet on that, and I don't know if they will to be honest.

[DomT4]

Yeah. I did put in a request to Apple a couple of months back along the lines of "Instead of either permitting no unsigned kexts or all unsigned kexts could we possibly permit a specific unsigned kext from the command line?" but they haven't got back to me yet on that, and I don't know if they will to be honest.

[mouse07410]

To the ability to run selected unsigned extensions, I'd prefer the ability to run selected self-signed (or signed with my own cert chain) extensions.

Here's the Stackoverflow thread for this issue http://stackoverflow.com/questions/26830800/cant-sign-kext-in-mavericks-yosemite for those who'd like to continue and/or explore it further.

[mouse07410]

To the ability to run selected unsigned extensions, I'd prefer the ability to run selected self-signed (or signed with my own cert chain) extensions.

Here's the Stackoverflow thread for this issue http://stackoverflow.com/questions/26830800/cant-sign-kext-in-mavericks-yosemite for those who'd like to continue and/or explore it further.

[MikeMcQuaid]

Since it appears that Apple has found a way to charge annual "rent" on its OS, I wonder what their response to your request would be (if any).

Enough with this silliness, please. Take it to the mailing list and/or install Linux where you can install whatever you want.

[MikeMcQuaid]

Since it appears that Apple has found a way to charge annual "rent" on its OS, I wonder what their response to your request would be (if any).

Enough with this silliness, please. Take it to the mailing list and/or install Linux where you can install whatever you want.

[mvhaen]

Any word on the progress for getting tuntap to work and how to install the package?

[mvhaen]

Any word on the progress for getting tuntap to work and how to install the package?

[DomT4]

Tuntap have released an upstream binary which is signed and works great. It's available on the Sourceforge download page. Was gonna give you a direct link, but SF is down right now.

[DomT4]

Tuntap have released an upstream binary which is signed and works great. It's available on the Sourceforge download page. Was gonna give you a direct link, but SF is down right now.

[mvhaen]

Ok thanks. I'll try downloading the binaries once SF is back up.

[mvhaen]

Ok thanks. I'll try downloading the binaries once SF is back up.

[DomT4]

https://downloads.sourceforge.net/project/tuntaposx/tuntap/20141104/tuntap_20141104.tar.gz

That's the one.

[DomT4]

https://downloads.sourceforge.net/project/tuntaposx/tuntap/20141104/tuntap_20141104.tar.gz

That's the one.

[DomT4]

I punted it to Homebrew/Cask to see if they have any interest in shipping it. Given there's no longer a way for Brew to ship it on Yosemite due to the unsigned issue, It'd be good to have something within the Brew ecosystem able to service users looking for an easier install.

[DomT4]

I punted it to Homebrew/Cask to see if they have any interest in shipping it. Given there's no longer a way for Brew to ship it on Yosemite due to the unsigned issue, It'd be good to have something within the Brew ecosystem able to service users looking for an easier install.

[colons]

I have no problem, for the moment, with running OS X with the kext security measures it had this time last year, and for the moment that is what I am doing. It's kind of a bummer that there's no way for idiots like me to install kexts from source with homebrew short of modifying formula in-place.

[colons]

I have no problem, for the moment, with running OS X with the kext security measures it had this time last year, and for the moment that is what I am doing. It's kind of a bummer that there's no way for idiots like me to install kexts from source with homebrew short of modifying formula in-place.

[MikeMcQuaid]

Closing this out as it's pretty much resolved now.

[MikeMcQuaid]

Closing this out as it's pretty much resolved now.

[DomT4]

Just to round my last post out, the Cask accepted tuntap, so you can now do brew cask install tuntap and you're good. I really would recommend the Cask for signed, upstream kexts; It delivers the simplicity of Homebrew. Our new fail message for tuntap courtesy of Mike's work the other day includes a reference to installing via the Cask. Signed upstream kexts are the way forwards, feel free to nag developers to release them where possible 😀.

[DomT4]

Just to round my last post out, the Cask accepted tuntap, so you can now do brew cask install tuntap and you're good. I really would recommend the Cask for signed, upstream kexts; It delivers the simplicity of Homebrew. Our new fail message for tuntap courtesy of Mike's work the other day includes a reference to installing via the Cask. Signed upstream kexts are the way forwards, feel free to nag developers to release them where possible 😀.

[jokeyrhyme]

My only issue with recommending Cask is that upgrade doesn't work as expected:

• Homebrew/homebrew-cask#4678
• Homebrew/homebrew-cask#309

[jokeyrhyme]

My only issue with recommending Cask is that upgrade doesn't work as expected:

• Homebrew/homebrew-cask#4678
• Homebrew/homebrew-cask#309

[DomT4]

Yeah, the Cask is imperfect. I've been asking myself for a while whether they were content just distributing packages, or whether they were going to manage those packages in the sense of ensuring they get updates. It's good to see the latter is at least on the agenda. When it comes to tuntap at least, releases aren't a super-regular thing because there isn't a need for them to be, so the chance of having an outdated tuntap installation any time soon is reasonably low, IMO.

[DomT4]

Yeah, the Cask is imperfect. I've been asking myself for a while whether they were content just distributing packages, or whether they were going to manage those packages in the sense of ensuring they get updates. It's good to see the latter is at least on the agenda. When it comes to tuntap at least, releases aren't a super-regular thing because there isn't a need for them to be, so the chance of having an outdated tuntap installation any time soon is reasonably low, IMO.

[MikeMcQuaid]

Homebrew has some bugs too. I think their project is good and I'd like to see us point to it more.

[MikeMcQuaid]

Homebrew has some bugs too. I think their project is good and I'd like to see us point to it more.

[DomT4]

Yeah, no system is perfect. The Cask is doing a major refactor of their backend at the moment, so Homebrew changes no longer break it unexpectedly, which should allow both Homebrew and the Cask to change backend code more without having to worry about breaking everything for someone else. Some interesting stuff planned going forwards.

[DomT4]

Yeah, no system is perfect. The Cask is doing a major refactor of their backend at the moment, so Homebrew changes no longer break it unexpectedly, which should allow both Homebrew and the Cask to change backend code more without having to worry about breaking everything for someone else. Some interesting stuff planned going forwards.