<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Oct 27, 2014, at 6:33 PM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></div></blockquote></div><div><br></div><div>Apple can blacklist signed code with more granularity than by certificate. Regardless, we don't need to pre-emptively manufacturer requirements on Apple's behalf; the contractual agreements specify Apple's requirements plainly enough.</div><div><br></div><div>-landonf</div><br></body></html>