<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:32, 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:03, Jeremy Huddleston Sequoia wrote:</span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Sep 2, 2016, at 05:19, 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></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>In my opinion, the actual implementation of codesigning should be in base:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>1) Create a self-signed certificate/identity for code-signing</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>2) Import certificate/identity into keychain</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>3) Add it to trust store (`security add-trusted-cert ...`)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>4) In activate phase, if requested in Portfile, codesign the binary</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>No, that is incredibly dangerous. code should not be signed during activate, it should be signed at build time. The packages that a user downloads from MacPorts should not be altered at activation time. Ideally, the packages they download should be codesigned by a MacPorts developer codesigning certificate.</span><br></blockquote><span></span><br><span>I do not want to bless binary archives produced on the buildbot or make</span><br><span>them special. MacPorts is not a binary-only distribution, we allow and</span><br><span>support local compilation of ports.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Yes, and users that build on their own can sign them however they want.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Binaries that we produce should be signed by MacPorts as a generally good security practice.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">The same system should be used for both purposes.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><blockquote type="cite"><blockquote type="cite"><span>Unsolved problems:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>For step 1), how to to automate certificate creation.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Don't. This should be a manual process. The user should create a keychain and specify the path to the keychain in macports.conf. If that's not set, we should just adhoc sign.</span><br></blockquote><span></span><br><span>Adhoc code-signing does not solve the problem at hand with gdb/lldb as</span><br><span>that requires a trusted certificate in keychain as far as I understand it.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Correct. Users that want to create their own debugger will need to sign the executable with a trusted certificate.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span>For what use case would ad-hoc code-signing be useful on macOS?</span></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Consistency and correctness.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span>What would be the benefit of adding an ad-hoc signature?</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">It's more of a correctness check at that point than a security check.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><blockquote type="cite"><span>We cannot click</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>that in Keychain Assistent. That means finding a way to do it</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>programmatically with other tools. As far as I see, this is just a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>standard x509 certificate which could be done with openssl, but which</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>extensions need to be enabled?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>For step 4), how to give user 'macports' access to the System.keychain</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>without entering a password?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Don't use System.keychain. A separate keychain should be used just for the codesigning. It should be password protected, and the user should be prompted for the password to unlock the keychain as part of 'port build'.</span><br></blockquote><span></span><br><span>Users just want to get a working gdb/lldb, they don't want to learn</span><br><span>stuff about keychain or code-signing. They would need to create an</span><br><span>identity with a specific name, know where to place it, and set the</span><br><span>correct trust on the certificate. All these factors will lead to user</span><br><span>errors and that makes the manual process not feasible in my opinion.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Automating it leads to attack vectors that are trivially exploitable. If you go down this road, you will introduce a very juicy exploit, and this project will loose trust of many users.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Yes, users make mistakes. Let such error-prone users just use our binaries and let experts do it themselves. Let's make it secure by default.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span>After some testing, I would no longer want to add the identity (private</span><br><span>key) to System.keychain, but instead keep it in a separate keychain</span><br><span>accessible by root only.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Yes. And also support keeping it encrypted with a passphrase that the user would be prompted for on use.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span>However, as far as I see, for trusting the certificate (public key) it</span><br><span>needs to be in System.keychain or taskgated will not accept it.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Yes, the certificate and public key needs to be there if self signed, but it's equally possible to use a certificate that has an existing chain of trust (e.g.: ADC-provided developer codesigning key)</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><blockquote type="cite"><blockquote type="cite"><span>As an alternative, how to import the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>identity (both private/public key) into a different keychain with</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>unlocked access?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It should be unlocked by the user providing the password to unlock the keychain.</span><br></blockquote><span></span><br><span>I definitely do not want my upgrades to get stalled by password dialogs.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">You would just need to provide it once (at the start of running port).</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">I already enter my password for sudo access when upgrading. This is just one more prompt.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span>That will only annoy users as when they have to type their password more</span><br><span>often.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Only the ones that opt into it, and they will understand the need and likely desire this functionality.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><br><span>Rainer</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>