大多数浏览器和
Developer App 均支持流媒体播放。
-
公证面面观
公证就是关于在分发前识别和拦截恶意的 Mac 软件,而无需 App Review 团队或 Mac App Store 的参与。这项功能在去年推出,并已被 Mac app 开发者广泛采用。这个讲座让您有机会深入了解公证工作流程并了解公证服务的最新功能。
资源
- Resolving common notarization issues
- Signing Your Apps for Gatekeeper
- Xcode Help: Upload a macOS app to be notarized
- 演示幻灯片 (PDF)
相关视频
WWDC23
WWDC22
WWDC21
WWDC20
WWDC19
-
下载
大家下午好 感谢今天来到这里 我是 Garrett 我是 Apple 的信任与执行团队的一员 今天我们在这里要 一同探讨关于公证的问题 以下是本次演讲的一个快速议程 我们将会首先 简单概述一下 公证到底是什么 以及一些 它能够提供的好处 然后我们将会讨论 为使你的软件公证 所需的 App 要求 最后我们会过一遍 公证你的软件 你所需要的 工作流程和工具
让我们开始吧 到底什么是公证 嗯 这是我们在 去年的 WWDC 上提出一个流程 来用于在分发之前 识别和阻断恶意软件 现在它已经是 Developer ID 程序的一个扩展 意味着你不需要注册或是 使用任何不同的证书 也就是说你可以 控制你的软件的 签名和分发 正如在引入公证之前一样
其关键是公证服务它对 Developer ID 签名的内容 执行自动安全检查 那么让我们了解一下 当你需要开始第一次公证你的软件时的工作流程
下面的这个图标解释了开发流程 并且本地开发 完全保持不变 你在你的桌面上 使用你的 Apple 开发人员证书 构建并签名 直到你有一个候选版本 此时你只需要 使用你的 Developer ID 证书进行签名 然后你可以将其 副本发送至 Apple 公证服务 来进行公证
当公证完成并 成功后公证服务 会发送回一个通行证 你可以将此通行证 在分发前加在你的软件上 它一旦被加上 软件就可以被分发 和之前一样
值得一提的是 这一工作流程 自去年起就没有变化 因此这只算是一个复习 我们去年没有谈到的是 当有人首次下载和使用你的软件时 会发生什么
当一个用户下载你的 加了通行证的软件并且 双击它来启动时 管理员会执行一次校验
它将会检查本地通行证 而且它也会通过 CloudKit 与公证服务联系 来检查通行证 只要通行证通过了检验 而且通行证与 你的 App 的内容相符 管理者会允许这个 App 运行 用户会看到正常的 首次启动提示
现在我想要提醒大家的是 公证并不是一个 App 审查 公证服务执行 一系列自动化的安全检查
去年我们设定了一个目标 即在一小时内大部分提交从 公证服务都能获得回应
而事实证明 在去年 99% 的 提交都能在 15 分钟内获得回应
而且公证 服务的状态现在位于 Apple 公共状态页上 因此你可以很轻松地查看 是否有可能造成问题的服务问题 那么公证能带来什么好处 嗯 好处有很多 因此我今天只强调 其中的几点 首先公证服务可以帮你防止 无意中发送恶意依赖项
其次 有强行运行的 App 在默认情况下 更安全 我们稍后会 详细讨论这一点 这可以防止你的 App 被攻击者滥用
第三 用户更有可能 下载和尝试新的软件 当他们知道 Apple 已经 针对可知的安全问题进行了扫描后
最后 公证还可以 为由你的 Developer ID 账户 公证过的软件提供 审计跟踪 你可以使用它来检查 提交历史记录 确保 你不想要从你的账户发布的软件没有被发布 这就是关于 公证的一点概述 现在让我们请出 Robert 来谈谈关于 公证你的软件所需的 App 要求 Robert 首先我想说的是 对于任何 你们之前发布的软件 它们都不需要满足任何新要求 你可以将现有的 已经分发的软件 按照原样提交公证 但是对于新的软件 你需要确保它能够 满足几个安全要求 特别是 它必须 被完全地和正确地签名 并且它需要采用强化运行 所谓新软件 我指的是 代码签名时间在 2019 年 6 月 1 日之后的软件
下面我们将会详细地介绍 这两者的含义 即正确的签名和 强化运行 因此首先 当你要完全签名时 你真的需要那么做 这包括捆绑包 Macho-O 程序安装包 无论它们在哪里 以及无论你的 程序安装包中是否有 Mach-O 是否在你的捆绑包中有安装包 无论它们 出现在你的产品中的任何地方 它们都需要被签名 它们都需要被正确地签名
所以 要正确签名意味着 你需要签署捆绑包 Macho-O 和代码 我等一下会 详细介绍代码 和你的 Developer ID App 证书 并确保 包含一个安全的时间戳
对于可执行文件 它们需要 打开强化运行 你不需要为 框架或动态库文件 或捆绑包打开强化运行 只是对可执行文件而言的
对于安装包你需要 使用你的 Developer ID 安装证书来签名 这与你的 Developer ID App 证书是不同的 所以要注意
另外 如果你选择 签名磁盘映像来避免网守 路径随机化 则必须 使用你的 Developer ID App 证书来签名 而且 包含一个安全的时间戳 如果你使用 Xcode 来构建你的软件包 你的软件 这很容易 如果你打开自动 代码签名 Xcode 能够 为你完成所有这些 但你必须要注意 如果你使用的是脚本构建阶段 或拷贝构建阶段 它们可能会在你的软件中 引入新的代码 而 Xcode 并不知道这些代码 那么你就 需要确保它们得到正确的签名 我提到了代码文件 当我们在几年前提出了代码签名后 我们在技术说明中记录了这些 叫做代码位置的内容 因此任何在 其捆绑包中出现的任何文件 都会被代码签名的 基础结构认为是代码 也就是说它们需要有一个附加签名 Mach-Os 在这方面是最好的 你可以将签名 嵌入到任何你放在 这些位置的 Mach-O 和 捆绑包中 但是如果你 放置了其他种类的文件 比如 JPEG 文件或者原始的二进制文件 这些文件需要被签名 但是 它们不会获取附加 签名 反之附加签名会 最终成为一种扩展属性 而这意味着当你在打包你的代码时 你必须确保扩展属性保持在那些位置中 为了避免需要过度小心 我们建议你 将一切不是 Macho-O 或是包含 Macho-O 的捆绑包的任何东西放置于 这些位置之外的地方 当构建你的 App 时 因此 当你在 Xcode 之外签名时 我们推荐使用 彻底性代码签名 这意味着你首先 在你的 App 中的 最深层嵌套的包或代码段签名 这种情况下 应该是 Updater.app 在 Sparkle 框架内 在 WatchingGrassGrow.app 之下 然后你向上移动一级 然后分别对每一项进行签名 请注意 当你签署 Sparkle 框架 或者 抓取 Sparkle 主要执行文件的 Sparkle 框架 以及 同时签署 updater.app 时 你需要分别去 WatchingGrassGrow.saver growGrass.dylib 以及 WatchingGrassGrowHelper
最终当你完成签名 所有这些后 你需要 在最顶层的捆绑包签署所有内容 这会签署最主要的 可执行文件 如你的 info. plist 所示
你们中有些人在 自定义工作流程中使用 -- Deep 标志 但那样需要额外注意 -- Deep 标志仅仅 在代码位置中寻找代码 而在这个案例中 growGrass.dylib WatchingGrassGrow.saver 以及 Updater.app 不会被当做是代码 它们会被当做是 资源来签名 而非 作为代码被签名 因此他们会被 拒绝公证 除非你愿意 多费劲做彻底性签名
可以在会后查看 Technote 2206 获取更多关于 彻底性签名和代码位置的信息
当你完全正确地签名了你的 软件 你需要确保 你的签名不会失效顾客 也就是说 你永远不应该 更改你的数据包中的文件 除非是安装或 更新期间 而且当你更新软件时 确保更新的结果 是在顾客系统中 正确的签名和公证过的 那么接下来我们会深入地 介绍强化运行 我们去年在 WWDC 已经介绍了强化运行 现在我们将会 提供更多细节 讨论它的 优势和配置问题 强化运行将 很多我们在 macOS 上所拥有的系统完整性保护 扩展到了你的 App 中 包括 运行代码签名执行 库验证 DYLD 环境变量保护 和调试保护 请注意 全部这些 保护是默认配置的 在 iOS 不能配置 但是在 macOS 是可以 通过任何开发人员都可以设置的 权限进行配置的 因此如果你在使用 Xcode 配置强化运行很简单 只需要进入签名与功能选项卡 确保 强化运行功能 可用于你的目标即可
然后你可以选择 你所需要的权限 来为你的项目 配置强化运行 通过勾选以下复选框 如果你正在使用 Xcode 之外的自定义工作流程 你可以 使用代码签名指令来 配置强化运行 为此你可以使用 代码签名的 options runtime 指令 确保你同时使用了 timestamp 选项 来确保在你的 App 上有一个 安全的时间戳 为了确认你已经 正确地配置了强化运行 使用代码签名下的 display 选项 设定 verbose 数值为 2 然后 在标志部分寻找 runtime 一词 另外需要注意的是 强化运行是版本化的 当你使用强化运行来 签名时 我们会记录下来 你所签名使用的版本 因此 如果我们想要 在未来为强化运行 添加更多保护 我们会确保 目前你的 App 已经测试过的那些 才会在未来的系统中应用
那么什么是运行代码签名执行呢 它防止在没有一个相关的 代码签名时 在你的进程中 创建一个可执行内存 通过首先确保 映射到你的进程中的所有字节 与其相关联的代码签名匹配 当它们被从磁盘中读取时来实现此目的 这不仅仅包括你的 Mach-O 中的可执行区域 也包括 非可执行映射 比如只读部分
并且防止执行 与其签名不相符的 已修改内存 因此 通过确认 我们正在从 磁盘中读取的内存如 它最初时一样 并且 不能被更改 我们能够确保你的 进程在运行中的一致性
那么其中一个 可能在使用 运行代码签名执行 出现的问题是 如果你的代码使用 JIT 来在你的 App 中 快速运行非本机代码 为此我们建议你 使用允许 JIT 授权 然后使用 MAP-JIT 标志 当你分配你的 你所编译代码的 读/写/执行内存时 这允许我们 对系统中的其他内存 保有其他的保护 同时给你提供 临时空间内存来 让你完成需要使用 JIT 的操作
如果你无法使用 MAP-JIT 标志 是因为你没有 你的 JIT 引擎的源代码访问权限 你可以使用允许未签名 可执行内存权限 这一操作将会降低 运行代码签名执行所提供的 安全性预测 仅确认对于每一个 具有代码签名的内存 所有你从磁盘读取的 字节都能够 实际上匹配 但是它会 允许修改任何 你的进程内的内存 并且允许创建 未签名的可执行区域
另一个我们看到的 一些开发人员遇到的挑战是 他们试图去修补一些 已经加载的系统框架 在已经使用了强化运行之后 我们不建议你这么做 你应该查看 是否有任何强化运行 功能实际上 解决了你这样做的原因 不过 如果你需要 允许未签名可执行内存权限 会执行你所 需要的操作 允许你修改 已映射的那些内存页 另外一个我们观察到的 有关于允许代码签名执行 的问题是 有些人在更新 App 时发生崩溃 这是因为代码签名 在内核中首次使用时 被锁存在文件中 这意味着如果你修改已经 运行和被签名的文件 它会不再匹配 内核中已有的签名 你就会看到 代码签名错误 我们的建议是 不要直接修改 磁盘中的已有文件 而是始终创建一个 具有更新内容的新文件 并移除旧文件 这会确保首次使用的新文件获取 其代码签名而不会 出现你所看到的代码签名错误
那么下面我们来讨论一下库验证
库验证可以保护 你的 App 免受代码注入和 动态库劫持 通过确保你的 App 仅加载由你的 团队或是 Apple 签名的代码 有的人或许会问 为什么需要加载由 Apple 签名的代码 好吧 请记住 所有的你从操作系统中 加载的框架和库 都是经过 Apple 签名的 因此你需要能够调用 它们并且将它们加载到你的进程中
请注意 库验证 可防止加载未签名的 和临时签名的代码 因此在开发过程中要保持小心 确保你在使用 Apple 开发证书 而并非关闭代码签名或 只是使用临时签名
因此 库验证可能会 对某些使用进程内插件 或生态系统的 App 带来挑战 我们建议你考虑 迁移到一个进程外 插件模型 因此你就不需要 将未知的第三方代码 加载到你的 App 中 但是假设你 做不到 你可以使用禁用 库验证权限 这一操作会允许加载 未签名和临时签名的插件 请注意 你可以自行 执行这个操作 不需要 执行任何运行代码或 选择执行相关权限 只需把禁用 库验证打开 当系统 发现你正在加载一个 临时签名或未签名的 插件时 它会降低 你进程的安全性 来允许此发生 因为你已经 告知系统想要加载未签名的插件
下一个是 DYLD 环境 变量保护 DYLD 环境变量 在你的开发过程中 对于加载 调试库到你的 App 中十分有用 当你在测试或使用一些库 或者一些正在构建 和正在开发的的框架 但还未准备好将它们 置入你的 App 中 仅是测试时 但是它们可能是危险的 因为在你的构建和 测试过程中可以做的 任何操作 攻击者都可以 在一个顾客系统中操作来 利用你的 App 可用的 权限或数据
因为这个原因 当你使用它时 强化运行会 默认阻止这些变量 如果你在调试过程中 需要使用 DYLD 环境变量 你可以在调试版本中 使用获取任务允许权限 请注意 Xcode 会在你创建调试时 自动为你启用 而当你创建发布版本时 自动为你关闭 但是请注意 如果你在 使用一个自定义工作流程 大多数情况下公证服务 无法接受具有 获取任务允许权限的二进制文件 因此在你向公证服务发送你的 发布版本之前 请确保已经关闭此权限
因此在少数情况下 我们看到 开发人员需要使用 DYLD 环境变量 当他们向用户发布他们的 App 时 同样 我们并不建议 你这么做 这可能非常危险 容易在顾客系统上 利用你的 App 但是如果你 需要的话 有一个权限可以 允许 DYLD 环境变量 这会允许 使用这些变量 并且被 公证服务所接受 下一个是调试保护 我们都知道调试器 允许开发人员来检视 寄存器和内存状态 修改进程内存 这意味着它们允许黑客 窃取敏感的用户数据 和注入恶意代码 因此在默认设置下 强化运行不允许 调试强化过程 但是如果你需要 在开发流中使用调试器 同样 获取允许任务权限 是你所需要的 与 DYLD 环境变量一起 获取任务允许权限 会允许你的 App 被调试
但是如果你使用 附带的调试器进行所有测试 需要小心 这会掩盖一些 其他你可能遇到的 强化运行相关的问题 尤其是有关运行代码签名执行的 基本上 一旦调试器 被附加 我们就不再能强制 执行代码签名了 因为调试器 例如设定一个断点 会自动更改你的进程中的数据 如果我们继续 强制执行它们 它们会立即崩溃 因此请确保测试 发布版本来查看 运行代码签名执行 可能具有的其他影响 然后如果你需要 构建一个调试版本 而不通过 Xcode 的获取任务允许 你可以将代码签名注入基础权限 等于你的 Xcode 项目中的无选项 来获取所有的调试设置 除了 获取任务允许之外
同样这在插件生态系统中 也可能成为一个挑战 因为插件开发人员需要在 他们想要加载的 App 中 调试他们的插件 因此 我们同样建议你 考虑进程外 插件模型 或考虑 将一个你的 App 的调试版本发送给 注册插件开发人员 以便他们有能力进行 测试 但你不需要将其发送给 所有的顾客 但是如果 绝对必要 公证服务 将会接受 获取任务允许权限 和禁用 库验证权的组合 来允许此工作流程
那么接下来我们简单谈谈 受保护资源访问
我们都知道 你的顾客使用他们的 Mac 来 存储大量的关于 他们的生活的信息 而 Mac 则 可以访问对安全性敏感传感器 为了 或者 一旦你采用了 强化运行 你的 App 需要声明 其需要访问其中任何 受保护资源的意图
我们提到了去年的 内容 但是如果你需要访问 这些资源中的任意一个 你需要 在你的主捆绑包上 获得授权 然后声明一个 与授权有关的 usage 字符串 以便当你的 App 试图访问 这些资源的其中一个时 系统可以提供一个对话 说明需要访问这一资源的原因 以便你可以获取 用户的同意
下面是一些本部分的 总结建议
这一授权关闭了 强化运行所提供的 安全性 而且它们可以被 任何查看你的 App 并试图发现 可以做点什么事情的人检视 一旦它被发送给顾客 因此要谨慎 只使用 你所需要的授权 并把它们 放在需要它们的进程中 如果你在你的 App 中有多个进程 多个可执行文件 它们不太可能都需要 同样的保护 你可能不需要在每一个进程中 都执行 JIT 你可能不需要将 插件加载到每一个进程中 因此只使用你所需要的授权 用于需要它们的进程 而且当你声明 资源访问时 确保 那些授权仅用于 你的 App 的主捆绑包 那些为你的捆绑包中 其他可执行文件所继承的包 它们不需要出现 只需要在主捆绑包上 现在我要把话筒交还给 Garrett 由他来介绍 实际提交公证需要怎么做 谢谢 Robert 现在你们已经了解了 在构建和设计 App 时所要考虑的一切 以便它为 公证做好准备 那么你如何 实际将它提交给公证服务呢 我们先简单了解下 公证的工作流程 不管你使用的是 Xcode 还是有一个 自定义工作流程 大概的工作流程是基本相同的
你提交 App 进行公证 检查 公证服务的状态 一旦公证完成 你会获得一个标签 你最终需要确认该标签 和公证是否成功 在我们进一步解释 这个问题之前 我们应该先讨论一下 何时应该提交什么 你至少需要提交 你所发行的全部软件 但你其实也可以更频繁地 上传提交 让开发人员机器之外 运行的一切 都可以作为公证服务上传提交 不过你也不需要 上传所有 CI build
团队中的任何人都可提交 软件以供公证 这和去年不同 当时只有特定的成员才能这样做
现在你已经做好准备 提交给公证服务了 如果你使用的是 Xcode 那就非常容易 它已被集成到了 档案与发行工作流程里 所以一旦你构建了一份档案 就可以打开 Xcode 管理器 正如你所见的这样 然后选择发行 App 就像你之前使用 Developer ID 所做的那样
选择 Developer ID 然后使用 上传选项 把一份拷贝 提交给公证服务 你会在上传过程中 看到进度条 上传结束后 你会回到管理器 你会注意到 状态已改为正在处理
公证服务结束后 你将把通知 推送到 Xcode 回到管理器后 你会注意到状态 已经变成了准备发行 在屏幕的右下角 导出已公证 App 的选项已经可用了
点按导出已公证 App Xcode 将为你 在 App 上附加通行证 这样它就完全准备好可以发行了
我们等一下会进一步说明 你将如何自我核实 因为那是自定义工作流程 与 Xcode 之间的共享工作流程
如果你不用 Xcode 那么用自定义工作流程进行提交 也一样的简单 首先你需要考虑 自己准备向公证服务提交什么 公证服务接受三种 主流格式 磁盘映像 安装包和 zip 档案 如果你的输出形式 是这三种之外的格式 那你就得先把它转换成 这三种格式之一 然后再发送到公证服务 别忘了 在你创建 zip 档案的时候 一定要包含 macOS 特定元数据 如扩展属性 如果你不知道该用哪种工具 可以在操作系统 内置的 ditto 和 Archive Utility 中获取支持
另外需要考虑的一个问题 就是如果你使用 自定义安装工具 如果你的自定义安装工具 要从网络上拉取内容 作为安装的一部分 或者如果你使用 自定义打包格式 就会稍微麻烦一点 如果你的自定义安装工具 有上面的需要 那么你也许要采取 两步公证程序 也就是把所有将要 放进磁盘里的内容 使用上面提到的三种支持格式之一 提交公证 对其附加通行证 然后再单独提交你的安装 App 现在你已经知道 应该把哪些内容提交公证服务了 那么具体该怎么操作呢 Xcode 10 及更新版本 包括一个命令行工具 它叫做 altool 它的作用就是和公证服务进行交互 如果你在用多个版本的 Xcode 那就要用 Xcode select 以确保 你选择了 Xcode 10 或更新版本 然后你就能用 带公证 App 指令的 altool 工具了 你需要用它提交 主捆绑包 ID 以及你想上传的文件
你需要验证 你的 Apple ID 如果你 看一看主页面 你会看到 使用钥匙串或者 环境变量的选项 这样一来你就不必 每次都输入密码了 公证上传完成后 你将收到一个 UID 请求 这个 UID 代表了 你提交的内容 你可以使用它和 公证信息指令 作为 altool 的一部分来 查看处理状态 你可以用这种方法来查看 公证何时结束 以及状态如何
这里是一个公证成功的例子 这里重要的是 日志文件 URL 无论公证是成功 还是出了问题 你都可以查看 日志文件 URL 了解更多信息 日志文件 URL 不会 长期存在 它们大约只会存在一天 所以你真的应该 获取一个新的 UID 这样当你需要公证信息时 就能获取新的日志文件 URL 了
这里的例子是一次 成功处理的 Json 日志 注意状态是已接受
如果它失败了 你就应该查看问题数组 在成功的公证里 这里应该是空白的 但如果出现了失败 这里就会出现对象 每一个对象代表 公证过程中的一个问题 它会显示哪个二进制文件 没有采用强化运行 或者是否有什么没有被正确签署 如果公证遭到拒绝 这里就是关键 如果成功了 你就应该查看 通行证内容 特别是如果你想 使用有趣的 打包软件方式的话 通行证内容应该列出 公证服务所发现的 每一个二进制文件 因此每个二进制文件的信息 都会被包含在通行证里 以供附加
如果你发现了 通行证内容里缺了什么 你就要尝试 发现问题所在 并再次尝试
无论你使用的是 Xcode 还是 altool 处理的提交 当公证服务完成后 你都会收到邮件 这里的例子是 一封代表公证成功的邮件 说明软件已经可以附加通行证了 然后就到了下一步
使用 Xcode 10 及以上版本内置的 一个叫 Stapler 的工具附加通行证 在这里你看到的例子 就是 Stapler 的附加指令
你可以用它直接向 安装包或磁盘映像附加通行证 现在要注意的是 你不能直接向 zip 文件附加通行证 你需要解压 zip 文件 向其内容附加通行证 然后再将其打包压缩准备发行
要注意的是 向命令行工具和库附加通行证的功能 目前还没有实现 虽然它们 也都可以而且应该被公证
附加通行证之后 下一步就是验证 一切都公证成功 取决于你想验证的东西 这一步会有小小的不同 但首先要做的事很简单 如果你只是想验证 某些东西附加了通行证 那你只需再次使用 Stapler 工具 在这里你可以看到 向 Stapler 工具输入了验证指令 让它去验证一个项目 正确地附加了通行证 而如果你想验证 某些未附加通行证 或者不是由你亲自附加通行证的项目 是否得到成功公证 该怎么做呢 在这种情况下 你就要用到 SPCTL 指令 它是 macOS 中内置的 运行把关评估的工具 取决于你想验证的内容 这一步也会有轻微的不同 但如果你想验证 一个 App 捆绑包 你可以使用 SPCTL 指令的 评估选项中的 详细输出了解 到 App 的路径
source 会告诉你 它是否得到了公证 经公证的 Developer ID 意味着 它成功地得到了公证 而如果它显示出 其它内容 那就说明 它没有得到公证 而如果你想验证 安装包是否得到了公证 你也可以像刚才那样 使用 SPCTL 指令 只不过再加上一个 类型选项把路径改成安装包
同样 这也会为你显示 source 如果它得到了 成功认证 你就会看到 经公证的 Developer ID
接下来 如果你想验证 已签署的磁盘映像又该怎么做呢
你也可以使用 基本相同的指令 只不过要换成 type open 并输入幻灯片上 列出的上下文
这会显示出和刚才一样的 输出 如果显示的是 经公证的 Developer ID 就说明已签署磁盘映像的公证成功了
如果你想验证 其它任何对象的公证状态 你就需要使用 代码签名指令
这里的例子就是使用 代码签名指令的验证功能 详细输出 以验证 一个非常特别的请求 notarized 然后是到 二进制文件的路径或者 你想验证的东西 输出的第三行会告诉你 explicit requirements satisfied 这说明你输入到 命令行的请求 已经成功得到满足 在这个例子里就说明 二进制文件得到了公证
如果它说的是 explicit requirement failed 那就说明二进制文件没有得到成功公证 关于验证公证的方法 就讲到这里 我想再调回去 讲一下 altool 的另一个用途 我在这次演讲开始时提过它
altool 还能通过 公证历史指令 为你显示你提交公证过的 所有软件的 公证历史
在这里你会看到 指令与输出的范例 它还能接受页码标注 你可以为所有的提交操作标注页码
我明白要消化的信息 对于这样一场短短的演讲来说是多了点 但是有几件重要的事 是我非常希望大家能够了解的 首先 非常重要的是 使用彻底性代码签名 正确签署你的软件 这很重要 不仅因为 把关工具能够验证 你的软件没有遭到篡改 也是出于公证的需要
第二 不要接受 你不需要的强化运行授权 想一想强化运行 能为你的 App 和用户带来的好处 记住你接受的每一次授权 都会降低 App 的安全性 所以要只接受你需要的授权
最后 要公证你发行的 所有软件 并为其附加通行证 以便其通过 macOS Catalina 的把关工具
感谢参加本次会议 如果你对公证有 进一步的兴趣 请到公证实验室来 它会紧接着本次会议 于下午 4 点开始 此外 本周还有其它的几个实验室 会开放 我们将探讨 安全 公证和签名相关的话题 谢谢大家 [掌声]
-
-
正在查找特定内容?在上方输入一个主题,就能直接跳转到相应的精彩内容。
提交你查询的内容时出现错误。请检查互联网连接,然后再试一次。