<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div><br>Sent from my iPhone...</div><div><br>On Sep 8, 2016, at 17:30, Rainer Müller <<a href="mailto:raimue@macports.org">raimue@macports.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote:</span><br><blockquote type="cite"><blockquote type="cite"><span>On Sep 5, 2016, at 03:49, Rainer Müller <<a href="mailto:raimue@macports.org">raimue@macports.org</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>My intention here is to describe a way how the code-signing can be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>automated. We do not gain much by providing a solution that still</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>requires manual interaction by the user. Generating a certificate and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>signing the binary should be completely transparent to the user.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>That obfuscation is very bad for security purposes. We should not hide this detail from users. It needs to be very explicit.</span><br></blockquote><span></span><br><span>At the moment it is very explicit. We have no automation at all and you</span><br><span>need to do all of the code-signing yourself or gdb/lldb will not work as</span><br><span>intended.</span><br><span></span><br><span>The alternative way, recommended in the notes of the gdb port, requires</span><br><span>disabling SIP to edit /System/Library/com.apple.taskgated.plist, which I</span><br><span>would consider even worse for security. See [1].</span><br><span></span><br><span>Where do you see a security risk in adding a new trusted cert?</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">You are describing a system to automatically create and automatically trust a code signing certificate that contains a private key in a file on disk that is not encrypted with a passphrase and only depends on file system ACLs to protect it.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">That is trivially insecure and attack-prone.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span>Consider that any software can already use your developer certificate</span><br><span>from your user keychain to sign whatever it wants. </span></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">No, it cannot. It requires my explicit authorization to do so. I must unlock the keychain for it to gain access.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span>You will not even be</span><br><span>asked when that happens.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">You should be if you set it up to do so. If you put your private keys in your login keychain, then the act of logging in with your password is what unlocks them. I don't consider that secure enough for my needs, so I place mine in another keychain which requires me to explicitly unlock it before use.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span>I propose we add an additional keychain, readable by root only that is</span><br><span>used to sign MacPorts binaries. As root is required to access it, your</span><br><span>security would be defeated anyway if anyone gets to it.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">It's great that only root can read it, but it should not be created automatically, added to any trusted store automatically, or stored unencrypted automatically. We should instead give good instructions for setting it up with either a self-signed or ADC-Provided code signing certificate.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">The user should just specify the path in macports.conf. If it is locked, we should prompt for the passphrase to unlock it before use.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><br><span>Rainer</span><br><span></span><br><span>[1] <a href="https://trac.macports.org/ticket/49815">https://trac.macports.org/ticket/49815</a></span><br><span>_______________________________________________</span><br><span>macports-dev mailing list</span><br><span><a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.org</a></span><br><span><a href="https://lists.macosforge.org/mailman/listinfo/macports-dev">https://lists.macosforge.org/mailman/listinfo/macports-dev</a></span><br></div></blockquote></body></html>