macos软件可信性取决于四层校验：gatekeeper准入、代码签名有效性、apple公证票据、运行时完整性保护。gatekeeper依据签名与公证状态放行app store、公证的developer id应用或手动授权应用；代码签名需证书有效且链至苹果根；公证须嵌入票据；sandbox、hardened runtime与sip共同保障运行时安全。
macOS 软件签名校验不是单一检查，而是一套分层验证流程。它不只看“有没有签名”，更关注“谁签的、是否过期、是否被篡改、是否通过苹果背书”。理解这四层逻辑，才能真正判断一个应用是否可信、如何修复警告、以及为何有时“点开仍被拦”。
Gatekeeper 是第一道门，但不是唯一守卫
Gatekeeper 默认只允许三类软件运行：App Store 下载的、经 Apple 公证（Notarized）的 Developer ID 签名应用、或用户手动放行的。它不验证代码本身，而是依据签名和公证状态做准入决策。
- macOS 10.9 起引入 Gatekeeper，10.14.5 后强制要求公证；未公证的 Developer ID 应用在 10.15+ 会触发“无法验证开发者”红色警告
- Gatekeeper 策略可临时绕过：系统设置 → 隐私与安全性 → 找到对应提示 → 点“仍要打开”；但这不修复问题，仅授权一次运行
- 完全禁用 Gatekeeper（
spctl --master-disable）不推荐，会削弱整机防护能力
代码签名是身份身份证，必须匹配本地证书链
签名本质是开发者用私钥对应用内容生成加密哈希，并附上由苹果信任根签发的证书。系统校验时需同时满足：证书有效、未被吊销、签名未被破坏、证书链可回溯至苹果根证书。
macOS Automator Services
下载
部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...
- 用
codesign -dv --verbose=4 /path/to.app查看签名详情：重点看 Authority（应为 Developer ID Application 或 Apple Distribution）、TeamIdentifier（非空且匹配开发者账号）、Timestamp（签名时间是否在证书有效期内） - 用
security find-identity -v -p codesigning确认本机钥匙串中是否存在对应证书；若显示 EXPIRED 或无结果，说明证书缺失或失效 - 证书权限需设为“允许所有应用程序访问此项目”，否则签名操作可能静默失败
Apple 公证是额外背书，需嵌入票据才能生效
公证不是重新签名，而是开发者将已签名的应用上传至 Apple 服务，由苹果扫描恶意行为并返回一张“票据”（ticket），再用 xattr 命令嵌入到应用中。系统启动时读取该票据完成最终放行。
- 检查是否含公证票据：
xattr -pl com.apple.quarantine /path/to.app，含 ticket=1 表示曾通过公证流程 - 验证公证结果：
spctl --assess --type execute --verbose=4 /path/to.app，输出 accepted 才代表签名+公证双通过 - 票据可能因证书吊销、应用更新后未重公证、或 macOS 时间偏差而失效；校准系统时间（开启自动同步）可解决部分“公证失效”误报
完整性保护贯穿始终，从文件到内核
签名验证只是起点。macOS 还通过多层机制防止运行时篡改：App Sandbox 限制应用能访问的资源；Hardened Runtime 强制启用运行时保护（如禁用代码注入）；System Integrity Protection（SIP）锁定系统关键路径，连 root 都无法修改 /System、/usr 等目录。
- 签名时建议添加
--options=runtime启用 Hardened Runtime，否则部分新 API（如屏幕录制权限）将不可用 - 使用 entitlements 文件声明所需权限（如辅助功能、全盘访问），缺失会导致功能异常，而非签名失败
- 内核扩展（kext）自 macOS 10.15 起必须单独签名+公证+用户授权，普通应用无需处理此项
