On 27 Oct 2015, at 20:27, Nima Fatemi nima@riseup.net wrote:
Ian Goldberg:
On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
Essentially, codesign only touches executable binaries in the .app (see that second link for info on how the binary's segments get moved around) and also adds an SC_Info directory for codesign/DRM metadata.
Wait; does that mean that things like configuration files, plugins, etc. are *not* signed?
There's a --deep option in `codesign` for this purpose.
From the man page:
When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
Apple recommends against signing with --deep, it's designed for verification: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple... https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG404 (Quoting the entire entry because Apple blocks Tor Exit nodes:)
Using the codesign Tool's --deep Option Correctly
When verifying signatures, add --deep to perform recursive validation of nested code. Without --deep, validation will be shallow: it will check the immediate nested content but not check that fully. Note that Gatekeeper always performs --deep style validation.
<>Important: While the --deep option can be applied to a signing operation, this is not recommended. We recommend that you sign code inside out in individual stages (as Xcode does automatically). Signing with --deep is for emergency repairs and temporary adjustments only.
Note that signing with the combination --deep --force will forcibly re-sign all code in a bundle.
Mozilla have also had issues with signing with --deep: https://bugzilla.mozilla.org/show_bug.cgi?id=989189 https://bugzilla.mozilla.org/show_bug.cgi?id=989189
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F