<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 27, 2014 at 8:26 PM, Landon J Fuller <span dir="ltr"><<a href="mailto:landonf@macports.org" target="_blank">landonf@macports.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Oct 27, 2014, at 5:36 PM, Dan Ports <<a href="mailto:dports@macports.org">dports@macports.org</a>> wrote:<br>
> Also, I think Apple mandates using a separate certificate for each<br>
> kext -- so we're stuck getting more certificates no matter what.<br>
<br>
</span>AFAIK it's still just a general "kexts allowed" extension set on the Apple-signed developer ID certificate.<br></blockquote><div><br></div><div>Mechanism and policy are two different things. I would not be surprised if the agreement specified use of a separate cert for each kext or group of closely related kexts, so they can revoke one without affecting others. A mechanism can't enforce this, and while you can ignore it because the mechanism doesn't enforce it, you risk Apple deciding that because they don't like one kext you signed they can disable all kexts you signed.</div></div><div><br></div>-- <br><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</div></div>