<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Oct 24, 2014, at 5:03 PM, Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Oct 23, 2014, at 11:24 AM, Landon J Fuller wrote:<br><blockquote type="cite"><br>On Oct 22, 2014, at 5:25 PM, Ryan Schmidt wrote:<br><br><blockquote type="cite">On Oct 22, 2014, at 1:40 PM, Dan Ports wrote:<br><br><blockquote type="cite">I haven't upgraded to Yosemite myself yet, but I'm hearing that in<br>10.10 the system refuses to load any unsigned kernel modules by<br>default.<br></blockquote><br>I can understand the security motivations behind this change. You don't want untrusted code running in your kernel.<br></blockquote><br>It’s no more untrusted than any other code being run from MacPorts :-)<br></blockquote><br>There's most certainly a difference in the potential for damage from bad kernel code vs. bad user code. One can cause a kernel panic; the other can’t.<br></blockquote><br></div><div>If you figure out how signing fixes panic-causing driver bugs, please let me know, because it doesn’t seem to be working for my own — properly-signed — kext code :-)</div><div><br></div><div>As far as I can see, it doesn’t even prevent hardware vendors from bricking compatible 3rd-party chipsets:</div><div><a href="http://arstechnica.com/information-technology/2014/10/windows-update-drivers-bricking-usb-serial-chips-beloved-of-hardware-hackers/"><span class="Apple-tab-span" style="white-space:pre"> </span>http://arstechnica.com/information-technology/2014/10/windows-update-drivers-bricking-usb-serial-chips-beloved-of-hardware-hackers/</a></div><div><br></div><div>That driver was signed by Microsoft and delivered via Windows Update. FTDI has since apologized:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://www.ftdichipblog.com/?p=1053">http://www.ftdichipblog.com/?p=1053</a></div><div><br></div><div>I agree that a kext requires a higher degree of trust, I just don’t think a single-vendor signing regime is a net win for users. Ultimately, the difference between DRM and security rests in who controls the keys. Given that Apple is now positioned to grandfather in existing kexts while blocking the general use of any new ones by simply denying kext signing requests, I’m not particularly enamored with policy changes — such as deleting ports and requiring upstream binary distributions — that make it easier for Apple to fully shut that gate even sooner.</div><div><br></div><div>-landonf</div></body></html>