4 ms·
- 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
by jakobegger 8y ago
- 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 8y agoThank 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 8y agoCode 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/