使用 EAS 更新进行端到端代码签名

生成私钥和相应的证书

¥Generate a private key and corresponding certificate

在此步骤中，我们将为你的应用生成密钥对和相应的代码签名证书。为 --key-output-directory 标志指定源代码控制之外的目录，以确保生成的私钥不会被意外添加到源代码控制中。

¥In this step, we will generate a key pair and corresponding code signing certificate for your app. Specify a directory outside of your source control for the --key-output-directory flag to ensure the generated private key isn't accidentally added to source control.

此命令生成一个密钥对以及一个要包含在应用中的代码签名证书：

¥This command generated a key pair along with a code signing certificate to be included in the app:

• ../keys/private-key.pem：密钥对的私钥。

  ¥../keys/private-key.pem: the private key of the key pair.

• ../keys/public-key.pem：密钥对的公钥。

  ¥../keys/public-key.pem: the public key of the key pair.

• certs/certificate.pem：配置为有效期为 10 年的代码签名证书。此文件应添加到源代码控制（如果适用）。

  ¥certs/certificate.pem: the code signing certificate configured to be valid for 10 years. This file should be added to source control (if applicable).

• 生成的私钥必须保密且安全。上面的命令建议在源代码控制之外的目录中生成和存储这些密钥，以确保不会意外将它们签入源代码控制。我们建议以与存储其他敏感信息（KMS、密码管理器等）相同的方式存储私钥，存储方式将改变在步骤 (3) 中发布更新所需的步骤。

  ¥The generated private key must be kept private and secure. The command above suggests generating and storing these keys in a directory outside of your source control to ensure they are not accidentally checked into source control. We recommend storing the private key in the same way you would store other sensitive information (KMS, password manager, and so on), and how you store it will vary the steps needed to publish an update in step (3).

• 公钥可以与私钥一起存储，但并不敏感。

  ¥The public key may be stored alongside the private key, but isn't sensitive.

• 证书应包含在项目中（签入源代码管理）。它包含公钥和验证代码签名的方法。下载签名更新时，使用此证书验证更新的签名。

  ¥The certificate should be included in the project (checked into source control). It contains the public key and a method for verifying code signatures. When a signed update is downloaded, the update's signature is verified using this certificate.

• 证书有效期的设置可能会根据应用的安全需求而有所不同。

  ¥The certificate validity duration is a setting that may vary based on the security needs of your app.

  • 较短的有效期将更频繁地需要 密钥轮换，但被认为是更好的做法，因为受损的私钥将更快到期，从而限制暴露。

    ¥A shorter validity duration will require key rotation more frequently but is considered better practice since a compromised private key will have a sooner expiration which limits exposure.

  • 较短的有效期会增加应用发布过程的开销，因为密钥必须更频繁地轮换。证书过期的二进制文件将不会应用新的更新。

    ¥Shorter validity durations add overhead to your app's release process as the key must be rotated more frequently. Binaries with expired certificates won't apply new updates.

  • 例如，对于公共 Expo Go 应用，Expo 将此值设置为 20 年，但对于具有更频繁分发的二进制文件的内部应用，仅为 1 年。我们计划每 10 年轮换一次密钥。

    ¥For example, Expo sets this value to 20 years for the public Expo Go app, but only 1 year for internal apps with binaries that are distributed more frequently. We plan to rotate our keys every 10 years.

配置你的项目以使用代码签名

¥Configure your project to use code signing

如果你使用持续原生生成 (CNG) 来生成原生项目，则 npx expo-updates codesigning configure 命令生成的 app.json 配置就是你所需要的。更改将在下次生成时应用于原生项目。

¥If you are using Continuous Native Generation (CNG) to generate your native projects, then the app.json configuration generated by the npx expo-updates codesigning configure command is all that you need. The changes will be applied to the native projects the next time they are generated.

{
"expo": {
  "updates": {
    "codeSigningCertificate": "./certs/certificate.pem",
    "codeSigningMetadata": {
      "keyid": "main",
      "alg": "rsa-v1_5-sha256"
    }
  }
}
}

如果你没有使用持续原生生成 (CNG) 来生成原生项目，则需要在你的应用 AndroidManifest.xml 和/或 Expo.plist 文件中配置代码签名。

¥If you are not using Continuous Native Generation (CNG) to generate your native projects, then you will need to configure code signing in your app AndroidManifest.xml and/or Expo.plist files.

<meta-data
android:name="expo.modules.updates.CODE_SIGNING_CERTIFICATE"
android:value="(insert XML-escaped certificate here)"
/>
<meta-data
android:name="expo.modules.updates.CODE_SIGNING_METADATA"
android:value="{&quot;keyid&quot;:&quot;main&quot;,&quot;alg&quot;:&quot;rsa-v1_5-sha256&quot;}"
/>

  <key>EXUpdatesCodeSigningCertificate</key>
  <string>-----BEGIN CERTIFICATE-----&#xD;
(insert XML-escaped certificate, it should look something like this)&#xD;
(spanning multiple lines with \r escaped but \n not escaped)&#xD;
+-----END CERTIFICATE-----&#xD;
</string>
  <key>EXUpdatesCodeSigningMetadata</key>
  <dict>
    <key>keyid</key>
    <string>main</string>
    <key>alg</key>
    <string>rsa-v1_5-sha256</string>
  </dict>

配置代码签名后，使用新的运行时版本创建新版本。代码签名证书将嵌入到这个新版本中。

¥With code signing configured, create a new build with a new runtime version. The code signing certificate will be embedded in this new build.

发布到 Apple App Store

¥Publish a signed update for your app

在使用 eas update 发布 EAS 更新期间，EAS CLI 会自动检测你的应用是否配置了代码签名。然后，它会验证更新的完整性并使用你的私钥创建数字签名。此过程在本地执行，因此你的私钥永远不会离开你的计算机。生成的签名会自动发送到 EAS 并与更新一起存储。

¥During an EAS Update publish using eas update, the EAS CLI automatically detects that code signing is configured for your app. It then verifies the integrity of the update and creates a digital signature using your private key. This process is performed locally so that your private key never leaves your machine. The generated signature is automatically sent to EAS to store alongside the update.

验证更新是否已加载

¥Verify that the update is loaded

在客户端上下载更新（此步骤由库自动补齐）。配置用于代码签名的步骤 (2) 中的构建会检查是否有可用的新更新。服务器以步骤 (3) 中发布的更新及其生成的签名进行响应。下载后但在应用之前，将根据嵌入的证书和包含的签名来验证更新。如果证书和签名有效，则应用更新，否则拒绝。

¥Download the update on the client (this step is done automatically by the library). The build from step (2) that is configured for code signing checks if there is a new update available. The server responds with the update published in step (3) and its generated signature. After being downloaded but before being applied, the update is verified against the embedded certificate and included signature. The update is applied if the certificate and signature are valid, and rejected otherwise.