This repository has been archived by the owner. It is now read-only.

Unsigned kexts cannot be used on 10.10 #31164

Closed
DomT4 opened this Issue Jul 27, 2014 · 68 comments

Comments

Projects
None yet
@DomT4
Contributor

DomT4 commented Jul 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Jul 27, 2014

Member

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).

Member

MikeMcQuaid commented Jul 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Jul 27, 2014

Contributor

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.

Contributor

DomT4 commented Jul 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Jul 28, 2014

Member

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.

Member

MikeMcQuaid commented Jul 28, 2014

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.

@adamv adamv added the 10.10 label Jul 28, 2014

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Jul 28, 2014

Contributor

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.

Contributor

DomT4 commented Jul 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@xiaket

xiaket Jul 29, 2014

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 commented Jul 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Jul 29, 2014

Contributor

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.

Contributor

DomT4 commented Jul 29, 2014

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.

@jacknagel jacknagel changed the title from Trouble Ahead: Kext signing in 10.10 to Unsigned kexts cannot be used on 10.10 Jul 30, 2014

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Jul 31, 2014

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 commented Jul 31, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Jul 31, 2014

Contributor

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.

  1. 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.
Contributor

DomT4 commented Jul 31, 2014

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.

  1. 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

This comment has been minimized.

Show comment
Hide comment
@xiaket

xiaket Aug 1, 2014

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 commented Aug 1, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Noctem

Noctem Aug 2, 2014

Contributor

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.

Contributor

Noctem commented Aug 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Aug 2, 2014

Contributor

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.

Contributor

DomT4 commented Aug 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Noctem

Noctem Aug 3, 2014

Contributor

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.

Contributor

Noctem commented Aug 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Aug 18, 2014

Contributor

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.

Contributor

DomT4 commented Aug 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MentalPower

MentalPower Aug 20, 2014

Contributor

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.

Contributor

MentalPower commented Aug 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Aug 20, 2014

Contributor

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.

Contributor

DomT4 commented Aug 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Oct 18, 2014

Contributor

Is it possible for us to sign kexts for bottles?

Contributor

jacknagel commented Oct 18, 2014

Is it possible for us to sign kexts for bottles?

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Oct 18, 2014

Contributor

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.

Contributor

DomT4 commented Oct 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Oct 19, 2014

Member

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

Member

MikeMcQuaid commented Oct 19, 2014

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

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Oct 19, 2014

Contributor

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.

Contributor

DomT4 commented Oct 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@iferguson90

iferguson90 Oct 20, 2014

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 commented Oct 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@sormy

sormy Oct 20, 2014

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

sormy commented Oct 20, 2014

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

@bh88

This comment has been minimized.

Show comment
Hide comment
@bh88

bh88 Oct 20, 2014

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 commented Oct 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Oct 20, 2014

Contributor

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.

Contributor

DomT4 commented Oct 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Oct 31, 2014

Contributor

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.

Contributor

DomT4 commented Oct 31, 2014

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

This comment has been minimized.

Show comment
Hide comment
@marblenix

marblenix Nov 4, 2014

Contributor

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).

Contributor

marblenix commented Nov 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Nov 5, 2014

Contributor

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.

Contributor

DomT4 commented Nov 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mouse07410

mouse07410 Nov 9, 2014

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 commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Nov 9, 2014

Member

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.

Member

MikeMcQuaid commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mouse07410

mouse07410 Nov 9, 2014

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 commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Nov 9, 2014

Contributor

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.

Contributor

DomT4 commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mouse07410

mouse07410 Nov 9, 2014

@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 commented Nov 9, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Nov 9, 2014

Contributor

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.

Contributor

DomT4 commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mouse07410

mouse07410 Nov 9, 2014

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 commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Nov 9, 2014

Contributor

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.

Contributor

DomT4 commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mouse07410

mouse07410 Nov 9, 2014

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 commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Nov 9, 2014

Member

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.

Member

MikeMcQuaid commented Nov 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mvhaen

mvhaen Dec 2, 2014

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

mvhaen commented Dec 2, 2014

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

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Dec 2, 2014

Contributor

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.

Contributor

DomT4 commented Dec 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mvhaen

mvhaen Dec 2, 2014

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

mvhaen commented Dec 2, 2014

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

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Dec 2, 2014

Contributor

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.

Contributor

DomT4 commented Dec 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@colons

colons Dec 19, 2014

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 commented Dec 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Dec 19, 2014

Member

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

Member

MikeMcQuaid commented Dec 19, 2014

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

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Dec 19, 2014

Contributor

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 😀.

Contributor

DomT4 commented Dec 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Dec 19, 2014

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

jokeyrhyme commented Dec 19, 2014

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

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Dec 19, 2014

Contributor

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.

Contributor

DomT4 commented Dec 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Dec 19, 2014

Member

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

Member

MikeMcQuaid commented Dec 19, 2014

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

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Dec 19, 2014

Contributor

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.

Contributor

DomT4 commented Dec 19, 2014

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.

@Homebrew Homebrew locked and limited conversation to collaborators Apr 15, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.