Implement -w flag, fix misc bugs

[captinc]

Changes:

• Implements the -w flag, which will perform a shallow sign. Only the main binary of the specified bundle will be signed, as specified by CFBundleIdentifier in Info.plist. Any nested bundles and/or stray binaries will be completely left alone and interpreted at face-value. Applicable only when the signing target is a bundle directory, and not a specific Mach-O file. -w can be used on any bundle, not just the root .app, including frameworks, appexes, and more. This is supposed to mimic the behavior of Apple's codesign tool. I know this is probably confusing, so at the bottom of this PR, I explain a real-world example of when -w can help. I did add -w to the manual entry....but only for the English version. The zh_CN and zh_TW versions will need to be updated separately, which I presume is a question for @asdfugil?

• Fixes -U support for blank passwords. Previously, if you specified -U along with a .p12 that doesn't have a password, you would still be prompted to enter the password. This PR fixes that.

• Fixes an alignment issue with LC_CODE_SIGNATURE. Previously, ldid aligned to a multiple of 8 bytes, but modern Apple platforms use a multiple of 16 bytes. This PR fixes that.

• Removes one particular _assert() that seems to be preventing legitimate cases. I'm not entirely sure why this assert() exists to begin with....but I ran some tests without it....and everything still seems to work as intended. In any case, during my tests, it was indeed preventing legitimate cases. ¯_(ツ)_/¯

• Forwards the user's choice of entitlements/requirements to nested bundles/stray binaries. Previously, when ldid signed nested bundles, it didn't forward the user's choice of requirements. It also didn't forward both entitlements and requirements when signing stray binaries. In some edge cases, this resulted in improperly entitled binaries. This PR fixes that. This should also resolve issue ldid strips entitlements of stray binaries even when using -s #24 reported by @opa334.

Lastly, a real-world example for when -w can help. Let's say you want to sign an app that has 3 Mach-O binaries: the main binary, an appex, and a framework. Let's also say that the main binary expects Entitlement A, the appex expects Entitlement B, and the framework expects no entitlements. Let's try to sign the app with existing ldid:

ldid -SEntitlements-all.plist Example.app

Uh oh. It signed all 3 binaries with the same entitlements, which is not what we want. Let's try again, this time introducing -w:

ldid -w -S Example.app/Frameworks/Something.framework
ldid -w -SEntitlements-B.plist Example.app/PlugIns/MessagesExtension.appex
ldid -w -SEntitlements-A.plist Example.app

Great! Now all 3 binaries have the correct entitlements that each of them expects.

Now, I know what you're thinking: "But can't you accomplish the same thing by signing each bundle in bottom-up order?"
Answer: Not really, no. Let's you sign the .appex first, and then sign the root .app. At the .app stage, ldid will go back and resign the appex....overwriting your entitlements and undoing what you did.

Apple's codesign tool operates in a similar way to -w, so -w tries to mimic that. When Xcode compiles a project, it individually codesigns each binary - it does not do a single codesign at the root .app, due to the same problem that I'm describing: different binaries potentially need different entitlements.

[asdfugil]

files changed 0

[captinc]

@asdfugil Try now, I was in the middle of making some changes and reorganizing things

[asdfugil]

shallow sign in the man page is not descriptive enough

[captinc]

@asdfugil Fixed, thanks! Let me know if there's anything more I can improve

[CRKatri]

LGTM 🤷‍♂️