
Ask HN: How to safely install Mac dev tools? - mleonhard
Many popular development tools for Mac are distributed in binary form without signatures on the binaries.<p>- https:&#x2F;&#x2F;brew.sh (Download and run an unsigned script.)<p>- https:&#x2F;&#x2F;atom.io&#x2F;download&#x2F;mac (Binary not signed.)<p>- https:&#x2F;&#x2F;emacsformacosx.com&#x2F;builds (Binaries are not signed.)<p>Is there any way to safely get such tools? At the moment I just need an HTML editor.
======
jakobegger
\- brew.sh: shell script is hosted on Github, transferred over HTTPS. Brew is
based on using Github to store repos for formulas (=packages), so you need to
trust Github. If you don't trust Github, don't use homebrew.

\- atom and emacs are both signed with a Developer ID certificate issued from
Apple. macOS doesn't even let you run unsigned binaries downloaded from the
internet by default. You can confirm using:

    
    
       $ codesign -vv ~/Downloads/Atom.app # verify
       $ codesign -dvv ~/Downloads/Atom.app # display signature info

~~~
mleonhard
Thank you for explaining this!

I right-clicked the apps and clicked "Get Info", found no signature info, and
assumed there are no sigs. Double-clicking shows a scary warning about the app
being downloaded from the Internet, with no signature information. Do you have
any idea why Apple decided not to show signatures?

~~~
jakobegger
Code Signatures are pretty complex on macOS. A macOS app can contain multiple
executables with embedded code signatures. Non-executable resources in bundles
are signed individually. Individual resources could potentially be signed with
different certificates.

Then there is the "designated requirement", which allows you to determine what
requirements there are on code signatures. Some resources could be optional
(eg. so that thinning the bundle by stripping 32bit code wouldn't invalidate
the signature). The designated requirement can also be overridden by the OS
(Apple has made it a lot stricter over the years, eg. unsigned resources in a
subfolder are no longer allowed).

Finally, sandbox entitlements are also embedded in the code signature, making
sure that you can't change sandbox permissions without invalidating the
signature (and re-signing).

For the user, all that matters is whether the code signature meets the
designated requirement (ie. is it valid) or not. I guess Apple could have
shown the identity of the developer who signed it, but since they don't do
extensive identity verification when you sign up for a developer account, that
would just be an opportunity for abuse...

If you want to know more about the code signature + sandbox permissions of an
app, I recommend the excellent "RB App Checker Lite" [1], but unfortunately it
seems that it is no longer maintained.

[1]:
[https://brockerhoff.net/RB/AppCheckerLite/](https://brockerhoff.net/RB/AppCheckerLite/)

------
atmosx
You can’t. Really, it’s impossible to vet everything.

I use littlesnitch and ClamXav as an extra security measure, along with what
the OS brings but as far as CLI third party tools go, we are all blind: pip,
npm, gems, random prexompiled go apps, docker containers and te list goes on
and on...

