i18n(ja) Japanese Translation for Distribute Section (Part 3) (#3379)

Co-authored-by: Vitor Ayres <gitkey@virtuaires.com.br>
This commit is contained in:
Junichi TAKAI (たかい じゅんいち)
2025-11-17 03:36:21 +09:00
committed by GitHub
parent 5925bc7631
commit 5c263166e4
8 changed files with 1236 additions and 1 deletions

View File

@@ -0,0 +1,27 @@
---
title: CrabNebula クラウド
i18nReady: true
---
import TranslationNote from '@components/i18n/TranslationNote.astro';
## CrabNebula Cloud で配布
[CrabNebula](https://crabnebula.dev) 社は、Tauri アプリケーション向けのサービスとツールを提供する公式 Tauri パートナーです。
[CrabNebula Cloud](https://crabnebula.dev/cloud/)CrabNebula クラウドは、Tauri アップデーターとシームレスに統合されたアプリケーション配布プラットフォームです。
「CrabNebula クラウド」は、アプリケーションのインストーラーと更新プログラムを世界中に配布できるコンテンツ配信ネットワークCDNを提供しつつ、コスト効率も良く、「ダウンロード数」指標も公開します。
「CrabNebula Cloud サービス」を利用すると、複数のリリース・チャネルやアプリケーション Web サイトのダウンロード・ボタンなどを簡単に実装できます。
クラウドを利用するように Tauri アプリを設定するのは簡単です: 行なうべきことは、自分の GitHub アカウントを使って「[クラウド・ウェブサイト]」にサインインすること、「所属組織」と「アプリケーション」を作成し「リリース」を作成するために「CLI」をインストールすること、そしてその「Tauri バンドル」をアップロードすることだけです。さらには、GitHub のワークフロー上で CLI を用いるプロセスの簡素化を行なう [GitHub Action] も提供されています。
詳細については、[CrabNebula Cloud ドキュメント](英語版)を参照してください。
[GitHub Action]: https://github.com/crabnebula-dev/cloud-release/
[クラウド・ウェブサイト]: https://web.crabnebula.cloud/
[CrabNebula Cloud ドキュメント]: https://docs.crabnebula.dev/cloud/
<div style="text-align: right;">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
</div>

View File

@@ -0,0 +1,266 @@
---
title: GitHub
i18nReady: true
---
import TranslationNote from '@components/i18n/TranslationNote.astro';
この章では、[GitHub Actions](https://docs.github.com/en/actions) の [tauri-action](https://github.com/tauri-apps/tauri-action) を使用して簡単にアプリをビルドアップロードする方法と、Tauri のアップデーターでアップデート用に新しく作成された GitHub リリースを照会する方法を説明します。
章の最後では、Linux Arm AppImages 用の、より複雑なビルド・パイプラインを設定する方法も説明します。
:::note[コード署名]
あなたのワークフローに Windows と macOS のコード署名を設定するには、以下の各プラットフォーム毎のガイドに従ってください:
- [Windows でのコード署名](/ja/distribute/sign/windows/)
- [macOS でのコード署名](/ja/distribute/sign/macos/)
:::
## 作業手順
`tauri-action` を設定するには、まず最初に GitHub リポジトリを設定する必要があります。この tauri-action は Tauri を自動的に初期化できるため、Tauri がまだ設定されていないリポジトリでも使用できます。必要な設定オプションについては、[tauri-action の readme](https://github.com/tauri-apps/tauri-action/#project-initialization)(英語版)を参照してください。
あなたの GitHub プロジェクト・ページの「Actions」タブに移動し、「新しいワークフロー New workflow」を選択し、「自分でワークフローを設定する Set up a workflow yourself」を選択します。そのファイルを下記の「[ワークフロー例](#ワークフロー例)」または GitHub サイトの「[Actions の例](https://github.com/tauri-apps/tauri-action/tree/dev/examples)」のいずれかのワークフローに置き換えてください。
## 設定
利用可能な設定項目については、「`tauri-action` の [readme](https://github.com/tauri-apps/tauri-action/#inputs)」ファイルを参照してください。
あなたのアプリが「リポジトリのルート」に置かれていない場合は、「`projectPath` 入力項目」を使用します。
「ワークフロー名」の修正や「トリガー」の変更、および「`npm run lint`」や「`npm run test`」といったステップの追加などは、自由に行なえます。重要なのは、**以下の行をワークフローの最後に残しておくこと**です。この行があなたのアプリのビルド・スクリプトを実行し、リリースするためです。
### トリガーの方法
以下の設定事例や「`tauri-action` の例」に示されているリリース・ワークフローでは、「`release` ブランチへのプッシュ」によってトリガーが行なわれます。このアクションは、アプリケーションのバージョンに基づいて、GitHub リリース用の「git タグ」と「タイトル」を自動的に作成します。
別の事例としては、「`app-v0.7.0`」のような「バージョン git タグ」のプッシュ時にワークフローを実行するようにトリガーを変更することもできます。
```yaml
name: 'publish'
on:
push:
tags:
- 'app-v*'
```
設定可能なトリガー内容の完全なリストについては、公式の [GitHub ドキュメント](https://docs.github.com/ja/actions/using-workflows/events-that-trigger-workflows) をご覧ください。
## ワークフロー例
以下の例は、`release` ブランチにプッシュするたびに実行されるように設定されたワークフローです。
このワークフローでは、Linux x64、Windows x64、macOS x64、macOS Arm64M1 以上)用のアプリをビルドしてリリースします。
このワークフローが実行する手順は次のとおりです:
1. `actions/checkout@v4` を使用してリポジトリを「チェックアウト」します。
2. アプリのビルドに必要な Linux システムの依存関係をインストールします。
3. `actions/setup-node@v4` を使用して、Node.js LTS長期サポート版とグローバル npm/yarn/pnpm パッケージ・データ用のキャッシュをセットアップします。
4. `dtolnay/rust-toolchain@stable` と `swatinem/rust-cache@v2` を使用して、Rust と「Rust のビルド成果物 artifact」アプリをテストまたはデプロイするために必要なファイル用のキャッシュをセットアップします。
5. フロントエンドの依存関係をインストールし、[`beforeBuildCommand`](/reference/config/#beforebuildcommand) として設定されていない場合は、Web アプリのビルド・スクリプトを実行します。
6. 最後に、`tauri-apps/tauri-action@v0` を使用して `tauri build` を実行し、成果物を生成して、GitHub リリースを作成します。
<TranslationNote lang="ja">
**成果物** artifact ソフトウェア開発における「中間生成物」を指す用語。日本語の標準訳は「成果物」ですが、その意味内容が把握しづらいのが難。Microsoft Terminology Search サイトには、artifact type に「ツールが公開するデータの種類で、・・・、例としては、ソースファイル、欠陥、要件、テスト結果、ビルドなど」との説明があります。
</TranslationNote>
```yaml
name: 'publish'
on:
workflow_dispatch:
push:
branches:
- release
jobs:
publish-tauri:
permissions:
contents: write
strategy:
fail-fast: false
matrix:
include:
- platform: 'macos-latest' # Arm 版 macs 用M1 以降)
args: '--target aarch64-apple-darwin'
- platform: 'macos-latest' # Intel 版 macs 用
args: '--target x86_64-apple-darwin'
- platform: 'ubuntu-22.04'
args: ''
- platform: 'windows-latest'
args: ''
runs-on: ${{ matrix.platform }}
steps:
- uses: actions/checkout@v4
- name: install dependencies (ubuntu only)
if: matrix.platform == 'ubuntu-22.04' # この項目は、上記で定義されたプラットフォーム値と一致する必要があります
run: |
sudo apt-get update
sudo apt-get install -y libwebkit2gtk-4.1-dev libappindicator3-dev librsvg2-dev patchelf
- name: setup node
uses: actions/setup-node@v4
with:
node-version: lts/*
cache: 'yarn' # この項目には、npm、yarn、pnpm のいずれかを設定
- name: install Rust stable
uses: dtolnay/rust-toolchain@stable # この項目には、dtolnay/rust-toolchain@nightly と設定
with:
# これらのターゲットは macOS ランナーでのみ使用されるため、Windows および Linux ビルドをわずかに高速化するために `if` 内に置きます
targets: ${{ matrix.platform == 'macos-latest' && 'aarch64-apple-darwin,x86_64-apple-darwin' || '' }}
- name: Rust cache
uses: swatinem/rust-cache@v2
with:
workspaces: './src-tauri -> target'
- name: install frontend dependencies
# `beforeBuildCommand` が設定されていない場合は、ここでフロントエンドをビルドすることも可能です
run: yarn install # 使用するものに応じて、ここを npm または pnpm に変更します
- uses: tauri-apps/tauri-action@v0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tagName: app-v__VERSION__ # このアクションにより、\_\_VERSION\_\_ がアプリのバージョンに自動的に置き換えられます
releaseName: 'App v__VERSION__'
releaseBody: 'See the assets to download this version and install.'
releaseDraft: true
prerelease: false
args: ${{ matrix.args }}
```
詳細な設定オプションについては、[`tauri-action`](https://github.com/tauri-apps/tauri-action) リポジトリとその [事例 examples](https://github.com/tauri-apps/tauri-action/blob/dev/examples/) を参照してください。
:::caution
GitHub Actions の [使用制限、支払い、管理](https://docs.github.com/ja/actions/learn-github-actions/usage-limits-billing-and-administration) に関するドキュメントをよくお読みください。
:::
## Arm ランナーによるコンパイル
このワークフローでは、[`pguyot/arm-runner-action`](https://github.com/pguyot/arm-runner-action) を使用して、エミュレートされた「Arm ランナー」上で直接コンパイルします。これにより、AppImage ツールに欠けているアーキテクチャ間のビルド機能を補完します。
:::danger
`arm-runner-action` は GitHub の標準ランナーよりも**はるかに**遅いため、ビルド時間に応じて課金されるプライベート・リポジトリでは注意が必要です。新規の `create-tauri-app` プロジェクトのキャッシュなしビルドでは約 1 時間かかります。
:::
```yaml
name: 'Publish Linux Arm builds'
on:
workflow_dispatch:
push:
branches:
- release
jobs:
build:
runs-on: ubuntu-22.04
strategy:
matrix:
arch: [aarch64, armv7l]
include:
- arch: aarch64
cpu: cortex-a72
base_image: https://dietpi.com/downloads/images/DietPi_RPi5-ARMv8-Bookworm.img.xz
deb: arm64
rpm: aarch64
appimage: aarch64
- arch: armv7l
cpu: cortex-a53
deb: armhfp
rpm: arm
appimage: armhf
base_image: https://dietpi.com/downloads/images/DietPi_RPi-ARMv7-Bookworm.img.xz
steps:
- uses: actions/checkout@v3
- name: Cache rust build artifacts
uses: Swatinem/rust-cache@v2
with:
workspaces: src-tauri
cache-on-failure: true
- name: Build app
uses: pguyot/arm-runner-action@v2.6.5
with:
base_image: ${{ matrix.base_image }}
cpu: ${{ matrix.cpu }}
bind_mount_repository: true
image_additional_mb: 10240
optimize_image: no
#exit_on_fail: no
commands: |
# Prevent Rust from complaining about $HOME not matching eid home
export HOME=/root
# Workaround to CI worker being stuck on Updating crates.io index
export CARGO_REGISTRIES_CRATES_IO_PROTOCOL=sparse
# Install setup prerequisites
apt-get update -y --allow-releaseinfo-change
apt-get autoremove -y
apt-get install -y --no-install-recommends --no-install-suggests curl libwebkit2gtk-4.1-dev build-essential libssl-dev libgtk-3-dev libayatana-appindicator3-dev librsvg2-dev patchelf libfuse2 file
curl https://sh.rustup.rs -sSf | sh -s -- -y
. "$HOME/.cargo/env"
curl -fsSL https://deb.nodesource.com/setup_lts.x | bash
apt-get install -y nodejs
# Install frontend dependencies
npm install
# Build the application
npm run tauri build -- --verbose
- name: Get app version
run: echo "APP_VERSION=$(jq -r .version src-tauri/tauri.conf.json)" >> $GITHUB_ENV
# TODO: Combine this with the basic workflow and upload the files to the Release.
- name: Upload deb bundle
uses: actions/upload-artifact@v3
with:
name: Debian Bundle
path: ${{ github.workspace }}/src-tauri/target/release/bundle/deb/appname_${{ env.APP_VERSION }}_${{ matrix.deb }}.deb
- name: Upload rpm bundle
uses: actions/upload-artifact@v3
with:
name: RPM Bundle
path: ${{ github.workspace }}/src-tauri/target/release/bundle/rpm/appname-${{ env.APP_VERSION }}-1.${{ matrix.rpm }}.rpm
- name: Upload appimage bundle
uses: actions/upload-artifact@v3
with:
name: AppImage Bundle
path: ${{ github.workspace }}/src-tauri/target/release/bundle/appimage/appname_${{ env.APP_VERSION }}_${{ matrix.appimage }}.AppImage
```
## トラブル・シューティング
### GitHub 環境トークン
GitHub トークンは、追加の設定を行なうことなく、各ワークフローの実行ごとに GitHub によって自動的に発行されます。このため、「シークレット」漏洩のリスクはありません。しかしながら、デフォルトではこのトークンには「読み取り権限」しか付与されていないため、ワークフローの実行時に「統合によってリソースにアクセスできません」アクセス権不足というエラーが表示される場合があります。その場合には、このトークンに「書き込み権限」を追加する必要があるかもしれません。権限を追加するには、「GitHub project settings」に移動し「`Actions`」を選択、「`Workflow permissions`」ワークフロー権限までスクロールダウンして、「Read and write permissions」読み取りと書き込み権限にチェックを入れてください。
GitHub トークンが、ワークフロー内の以下の行を通じてワークフローに渡されていることを確認できます。
```yaml
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
<div style="text-align: right;">
【※ この日本語版は、「Apr 9, 2025 英語版」に基づいています】
</div>

View File

@@ -0,0 +1,173 @@
---
title: Android でのコード署名
sidebar:
label: Android
order: 15
i18nReady: true
---
import { Tabs, TabItem } from '@astrojs/starlight/components';
import { Code } from '@astrojs/starlight/components';
import TranslationNote from '@components/i18n/TranslationNote.astro';
「Play ストア」でアプリを公開するには、「デジタル証明書」を使用してアプリに署名する必要があります。
「Android アプリ・バンドル」と「APK」は、配布用にアップロードする前に署名する必要があります。
<TranslationNote lang="ja">
**APK** Android Application Package Google によって開発された Android 専用ソフトウェア・パッケージのファイル・フォーマット。
</TranslationNote>
Google はまた、「Play ストア」で配布される「Android アプリ・バンドル」に対して別の署名方法も提供しています。
詳細については、[Play アプリ署名の公式ドキュメント(英語)] をご覧ください。
## Keystore の作成と Key のアップロード
<TranslationNote lang="ja">
**Keystore** キーストア(「鍵保管所」の意)。証明書と秘密鍵のリポジトリとして機能するバイナリ・ファイル。[公式ドキュメント](https://developer.android.com/studio/publish/app-signing?hl=ja#certificates-keystores)
</TranslationNote>
Android の署名では、公式の `keytool` CLI を使用して生成される「Java Keystore ファイル」が必要です:
<Tabs syncKey="OS">
<TabItem label="macOS/Linux">
```
keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload
```
</TabItem>
<TabItem label="Windows">
```
keytool -genkey -v -keystore $env:USERPROFILE\upload-keystore.jks -storetype JKS -keyalg RSA -keysize 2048 -validity 10000 -alias upload
```
</TabItem>
</Tabs>
このコマンドは、「`upload-keystore.jks` ファイル」をホーム・ディレクトリに保存します。
別の場所に保存したい場合は、`-keystore` パラメータに渡す引数を変更します。
:::tip
- `keytool` コマンドが PATH 内に存在していない場合があります。
Android Studio とともにインストールされる JDKJava Development Kit内にインストールされている可能性があります。
<Tabs syncKey="OS">
<TabItem label="Linux">
<Code code="/opt/android-studio/jbr/bin/keytool ...args" lang="sh" />
**Android Studio のディレクトリ・パスは Linux
のディストリビューションによって異なります**
</TabItem>
<TabItem label="macOS">
<Code
code="/Applications/Android\ Studio.app/Contents/jbr/Contents/Home/bin/keytool ...args"
lang="sh"
/>
</TabItem>
<TabItem label="Windows">
<Code
code="C:\\Program Files\\Android\\Android Studio\\jbr\\bin\\keytool.exe ...args"
lang="sh"
/>
</TabItem>
</Tabs>
:::
:::caution[セキュリティ警告]
「`keystore` ファイル」は**非公開**にして、パブリック・ソース管理ではチェックを入れないでください。
:::
詳細については、[Android 公式ドキュメント](https://developer.android.com/studio/publish/app-signing?hl=ja#generate-key) を参照してください。
## 署名鍵の設定
「`[project]/src-tauri/gen/android/keystore.properties`」という名前のファイルを作成します。このファイルにはあなたの「キーストア」への参照を含んでいます:
```
password=<password defined when keytool was executed>
keyAlias=upload
storeFile=<location of the key store file, such as /Users/<user name>/upload-keystore.jks or C:\\Users\\<user name>\\upload-keystore.jks>
```
:::caution[セキュリティ警告]
「`keystore.properties` ファイル」は非公開にし、パブリック・ソース管理ではチェックを入れないでください。
:::
通常、このファイルは CI/CD プラットフォームで生成されます。以下のスニペットは、GitHub Actions のジョブ・ステップの例です:
```yml
- name: setup Android signing
run: |
cd src-tauri/gen/android
echo "keyAlias=${{ secrets.ANDROID_KEY_ALIAS }}" > keystore.properties
echo "password=${{ secrets.ANDROID_KEY_PASSWORD }}" >> keystore.properties
base64 -d <<< "${{ secrets.ANDROID_KEY_BASE64 }}" > $RUNNER_TEMP/keystore.jks
echo "storeFile=$RUNNER_TEMP/keystore.jks" >> keystore.properties
```
この例では、キーストアは `base64 -i /path/to/keystore.jks` を使用して base64 エンコード後エクスポートされ、「`ANDROID_KEY_BASE64` シークレット」として設定されます。
### 証明鍵を使用するための Gradle 設定
「`[project]/src-tauri/gen/android/app/build.gradle.kts` ファイル」を編集し、リリース・モードでアプリをビルドするときに「アップロード・キー」を使用するように、Gradle を設定します。
1. 必要となるインポート文をファイルの先頭に追加します:
```kotlin
import java.io.FileInputStream
```
2. 「`buildTypes` ブロック」の前に「`release` 署名設定signing config」を追加します
```kotlin {3-12}
signingConfigs {
create("release") {
val keystorePropertiesFile = rootProject.file("keystore.properties")
val keystoreProperties = Properties()
if (keystorePropertiesFile.exists()) {
keystoreProperties.load(FileInputStream(keystorePropertiesFile))
}
keyAlias = keystoreProperties["keyAlias"] as String
keyPassword = keystoreProperties["password"] as String
storeFile = file(keystoreProperties["storeFile"] as String)
storePassword = keystoreProperties["password"] as String
}
}
buildTypes {
...
}
```
3. 「`buildTypes` ブロック」の「`release` 設定」にある新しい「`release` 署名設定」を使用します:
```kotlin {3}
buildTypes {
getByName("release") {
signingConfig = signingConfigs.getByName("release")
}
}
```
以上で、アプリのリリース・ビルドが自動的に署名されるようになります。
[Play アプリ署名の公式ドキュメント(英語)]: https://support.google.com/googleplay/android-developer/answer/9842756?hl=en&visit_id=638549803861403647-3347771264&rd=1
<div style="text-align: right;">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
</div>

View File

@@ -0,0 +1,103 @@
---
title: iOS でのコード署名
sidebar:
label: iOS
order: 14
i18nReady: true
---
import TranslationNote from '@components/i18n/TranslationNote.astro';
iOS でのコード署名は、公式 [Apple App Store] または欧州連合EUの代替マーケットプレイスを通じてアプリケーションを配布する場合、および一般的にはエンド・ユーザーのデバイスにインストールして実行する場合、に必要です。
## 事前準備
iOS でコード署名を行なうには、[Apple Developer] プログラムに登録する必要があります。このプログラムの費用は執筆時点では年間 99 米ドルです。
コード署名を実行するための Apple デバイスも必要です。これは「署名プロセス」と「Apple の利用規約」で必須となっています。
iOS アプリケーションを配布するには、App Store Connect に登録された「バンドル識別子」、適切な「iOS コード署名証明書」、およびこれらをリンクさせ、あなたのアプリが使用する iOS 機能を有効化する「モバイル・プロビジョニング・プロファイル」が必要です。
これらの必要情報は、Apple 統合開発環境である「Xcode」によって自動的に管理することも、手作業で提示することもできます。
## 自動署名
iOS アプリを配布用にエクスポートするには、アプリへの「署名」と「プロビジョニング」の管理を Xcode に任せるのが最も便利な方法です。
Xcode は、「バンドル識別子」を自動的に登録し、iOS 機能の変更を管理し、エクスポート方法に基づいて適切な「証明書」を構成します。
「自動署名」はデフォルトで有効化されており、ローカル・マシンで自動署名を使用する場合には、Xcode に設定されたアカウントを使用して認証されます。
自分のアカウントを登録するには、Xcode アプリケーションを開き、`Xcode > Setting`設定メニューで「Settings設定」ページを開き、「アカウント」タブに切り替えて `+` アイコンをクリックします。
「自動署名」を CI/CD プラットフォームで使用するには、「App Store Connect API キー」を作成し、環境変数の `APPLE_API_ISSUER`、`APPLE_API_KEY`、および `APPLE_API_KEY_PATH` を定義する必要があります。
[App Store Connect のユーザーとアクセス・ページ] を開き、「統合 Integration」タブを選択して、「追加 Add」ボタンをクリックして、「名前」と「管理者アクセス Admin access」を選択します。
`APPLE_API_ISSUER`(発行者 IDはキー・テーブルの上側に表示され、`APPLE_API_KEY` はそのテーブルの「キー ID 列」の値です。
「秘密鍵 private key」のダウンロードも必要ですが、これは一回だけ実行でき、ページをリロードした後にのみ表示されます新たに作成されたキーのテーブル行に「ボタン」が表示されます
「秘密鍵」ファイルのパスは、環境変数の `APPLE_API_KEY_PATH` を介して指定する必要があります。
## 手動署名
iOS アプリに手作業で署名するには、環境変数を使用して「証明書」と「モバイル・プロビジョニング・プロファイル」を提示します:
- **IOS_CERTIFICATE** Keychainキーチェーンからエクスポートされた「証明書」の base64 エンコード表現。
- **IOS_CERTIFICATE_PASSWORD** Keychain からエクスポートするときに設定された証明書のパスワード。
- **IOS_MOBILE_PROVISION**: プロビジョニング・プロファイルの base64 エンコード表現。
次項では、これらの値を取得する方法について説明します。
### 署名証明書
「Apple Developer」に登録後、[証明書 Certificate] ページに移動して、新しい「Apple Distribution 証明書」を作成します。
その新しい証明書をダウンロードし、macOS Keychain にインストールします。
「証明書キー」をエクスポートするには、「キーチェーン・アクセス」アプリを開き、「証明書のデータ項目」を展開後、「キー項目」を右クリックして「Export \<key-name\>」項目を選択します。
エクスポートされた「.p12 ファイル」(公開鍵暗号システム・ファイル)のパスを選択し、そのエクスポート・パスワードを覚えておいてください。
次の `base64` コマンドを実行して証明書を base64 にエンコード変換し、それをクリップボードにコピーします:
```
base64 -i <path-to-certificate.p12> | pbcopy
```
これで、クリップボード内の値は、署名証明書の base64 エンコード表現です。
これを保存し、環境変数 `IOS_CERTIFICATE` の値として使用します。
証明書のパスワードは変数の `IOS_CERTIFICATE_PASSWORD` に設定する必要があります。
:::tip[証明書タイプの選択]
それぞれのエクスポート方法に応じて適切な「証明書タイプ」を使用する必要があります:
- **debugging**「デバッグ」 Apple ソフト開発または iOS アプリ開発用
- **app-store-connect**「App Store 接続」 Apple ソフトの配布または iOS アプリの配布用App Store Connect「ストア配布」と Ad Hoc「配布先限定」
- **ad-hoc**「アド・ホック暫定 Apple ソフトの配布または iOS アプリの配布用App Store Connect「ストア配布」と Ad Hoc「配布先限定」
:::
### プロビジョニング・プロファイル(アプリ証明書)
さらに、アプリケーションの「プロビジョニング・プロファイル」も提示する必要があります。
Apple Developer サイトの [Identifiers](識別子)ページで、新しい App ID を作成し、その「バンドル ID」値と [`identifier`] 設定に入力された「識別子」の内容とが一致していることを確認します。
次に、[Profiles](プロファイル)ページに移動して、新しい「プロビジョニング・プロファイル」を作成します。
App Store 経由で配信する場合は、「App Store Connect」プロファイルを使用する必要があります。
適切な「アプリ ID」を選択し、以前に作成した「証明書」をリンクします。
プロビジョニング・プロファイルを作成したら、それをダウンロードし、以下の `base64` コマンドを実行してプロファイルを base64 形式に変換し、クリップボードにコピーします:
```
base64 -i <path-to-profile.mobileprovision> | pbcopy
```
クリップボード内の値は、「プロビジョニング・プロファイル」の base64 エンコード表現です。
この値を保存し、環境変数の `IOS_MOBILE_PROVISION` 値として使用します。
さあこれで、iOS アプリケーションがビルドされて App Store で配布できるようになります。
[証明書 Certificate]: https://developer.apple.com/account/resources/certificates/list
[Apple Developer]: https://developer.apple.com
[Apple App Store]: https://www.apple.com/app-store/
[App Store Connect のユーザーとアクセス・ページ]: https://appstoreconnect.apple.com/access/users
[Identifiers]: https://developer.apple.com/account/resources/identifiers/list
[`identifier`]: /reference/config/#identifier
[Profiles]: https://developer.apple.com/account/resources/profiles/list
<div style="text-align: right;">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
</div>

View File

@@ -0,0 +1,89 @@
---
title: Linux でのコード署名
sidebar:
label: Linux
order: 13
i18nReady: true
---
import TranslationNote from '@components/i18n/TranslationNote.astro';
この章では、Linux パッケージのコード署名に関する情報を提供します。
Linux であなたのアプリケーションがデプロイ(公開)される際にアーティファクト(成果物)への署名は必要とはされていませんが、公開されたアプリケーションに対する信頼性を高めるために署名が利用できます。
バイナリ・ファイルに署名を行なうと、エンド・ユーザーはそのバイナリが本物であり、信頼できない第三者によって改変されていないことを検証できます。
## AppImages への署名
[AppImage] フォーマットによる配布では、公開鍵暗号方式の「gpg」または「gpg2」を用いた署名が可能です。
### 事前準備(必要なもの)
「署名用の鍵」を用意する必要があります。新しい鍵は以下を使用して生成できます:
```shell
gpg2 --full-gen-key
```
詳細については、gpg または gpg2 の「[公式文書]」を参照してください。
「秘密鍵 private key」と「公開鍵 public key」を安全な場所にバックアップ保存するように特段の注意を払ってください。
### 署名
以下の「環境変数」を設定し、AppImage に署名を埋め込みます:
- **SIGN** AppImage に署名するには `1` に設定します。
- **SIGN_KEY** 署名に特定の「GPG キー ID」を使用するためのオプション変数です。
- **APPIMAGETOOL_SIGN_PASSPHRASE** 署名鍵の「パスワード」。未設定の場合、gpg がダイアログを表示しますので、パスワードを入力できます。CI/CD プラットフォームでビルドする場合、この設定は必須です。
- **APPIMAGETOOL_FORCE_SIGN**: デフォルトでは、たとえ署名が失敗しても AppImage が生成されます。エラー発生時に処理を終了させるには、この変数に `1` を設定してください。
次のコマンドを実行すると、AppImage に埋め込まれた署名を表示できます:
```shell
./src-tauri/target/release/bundle/appimage/$APPNAME_$VERSION_amd64.AppImage --appimage-signature
```
$APPNAMEアプリ名と $VERSIONアプリ・バージョンの値は、あなた自身のアプリ情報に基づいて、正しい値に変更する必要があることに注意してください。
:::caution
**The signature is not verified署名が検証されていません**
AppImage は署名の検証を行なわないため、ファイルが改竄されているかどうかの確認を AppImage に頼ることはできません。
ユーザー側で、AppImage 検証ツールを使用してその署名を手作業で検証する必要があります。
これを行なうために、あなたの「キー ID」を安全確実な認証チャネルTLS 経由で提供される Web サイトなど)経由で公開し、エンドユーザーが閲覧・検証できるようにする必要があります。
詳細については、[公式 AppImage ドキュメント] を参照してください。
:::
[公式 AppImage ドキュメント]: https://docs.appimage.org/packaging-guide/optional/signatures.html
### 署名の検証
AppImage の「検証ツール」は、[ここから](https://github.com/AppImageCommunity/AppImageUpdate/releases/tag/continuous) ダウンロードできます。
`validate-$PLATFORM.AppImage` ファイルの適切なものを選択してください。〔《訳注》 蛇足ながら `$PLATFORM` の部分は、使用している PC のアーキテクチャー名です。以下、同様。〕
**署名の検証**には、次のコマンドを実行します:
```shell
chmod +x validate-$PLATFORM.AppImage
./validate-$PLATFORM.AppImage $TAURI_OUTPUT.AppImage
```
署名が有効な場合、出力は次のようになります:
```
Validation result: validation successful
Signatures found with key fingerprints: $KEY_ID
====================
Validator report:
Signature checked for key with fingerprint $KEY_ID:
Validation successful
```
[AppImage]: /ja/distribute/appimage/
[公式文書]: https://docs.releng.linuxfoundation.org/en/latest/gpg.html#
<div style="text-align: right;">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
</div>

View File

@@ -0,0 +1,211 @@
---
title: macOS でのコード署名
sidebar:
label: macOS
order: 11
i18nReady: true
---
import TranslationNote from '@components/i18n/TranslationNote.astro';
自分のアプリケーションを [Apple App Store] に掲載し、ブラウザからダウンロードされたときに、「このアプリケーションは破損しているため起動できません」という警告メッセージが表示されないようにするためには、macOS での「コード署名」が必要です。
## 事前準備
macOS で「コード署名」を行なうには、「[Apple Developer] アカウント」開発者アカウントが必要です。アカウントは「有料プラン」年間99ドルまたは「無料プラン」テストおよび開発目的のみのどちらかになります。また、コード署名を行なう Apple デバイスも必要です。これは署名手続きと Apple 社の利用規約で規定されています。
:::note
無料の「Apple Developer アカウント」を使用する場合、あなたのアプリケーションはソフトウェア公証(ノータリゼーション)を受けることができず、アプリを開いたときに未認証として表示されることに御留意ください。
:::
## 署名
macOS のコード署名を設定するには、「Apple コード署名証明書」を作成し、それを Mac コンピュータのキーチェーンにインストールするか、CI/CD プラットフォームで使用するためにエクスポートする必要があります。
### 署名証明書の作成
新しい「署名証明書」を作成するには、Mac コンピューターから「証明書署名リクエストCSRファイル」を生成する必要があります。
「コード署名」用の CSR を作成する方法については、[証明書署名リクエストを作成する] を参照してください。
<TranslationNote lang="ja">
**CSR** 原文 Certificate Signing Request の略。「証明書署名リクエスト(要求)」
</TranslationNote>
あなたの「Apple Developer アカウント」で、[Certificates, IDs & Profiles のページ] に移動し、「`Create a certificate`(証明書の作成)」ボタンをクリックして、新しい証明書を作成するためのインターフェイスを開きます。
そこで適切な「証明書タイプ」を選択してくださいApp Store にアプリを送信する場合は「`Apple Distribution`Apple 配信」を、App Store 外でアプリを配布する場合は「`Developer ID Application`(開発者 ID アプリケーション」を選択します)。
次に「CSR証明書署名リクエストファイル」をアップロードすると、証明書が作成されます。
:::note
「Apple Developerアカウント」の所有者`Account Holder`のみが「_Developer ID Application_ 証明書」を作成できます。ただし、異なるユーザー・メールアドレスで CSR を作成することで、別の Apple ID に関連付けることができます。
:::
### 証明書のダウンロード
[Certificates, IDs & Profiles のページ] 上で、使用する「証明書」をクリックし、「`Download`(ダウンロード)」ボタンをクリックします。
すると「`.cer` ファイル」が保存され、このファイルを開くとキーチェーンに証明書がインストールされます。
### Tauri の設定
ローカル・マシン上で macOS アプリをビルドするときや、CI/CD プラットフォームを使用するときに、この証明書を使用するように Tauri を設定できます。
#### ローカル署名
あなたの Mac コンピュータのキーチェーンに証明書をインストールすることで、コード署名にその証明書を使用するように Tauri を設定できます。
証明書のキーチェーン・エントリ名は `signing identity`(署名本人確認)を表しており、次のコマンドを実行して確認することもできます:
```sh
security find-identity -v -p codesigning
```
この「本人確認 identity」は、[`tauri.conf.json > bundle > macOS > signingIdentity`] の設定オプション、または環境変数の `APPLE_SIGNING_IDENTITY` を介して得られます。
:::note
「署名証明書signing certificate」は、あなたの Apple ID に関連付けられている場合にのみ有効です。
有効でない証明書は、「_Keychain Access > My Certificates_」タブや「_security find-identity -v -p codesigning_」の出力には表示されません。
証明書が正しい場所にダウンロードされない場合は、「.cer ファイル」をダウンロードする際に、「デフォルト・キーチェーン」の下にある _キーチェーン・アクセス_ で「ログイン」オプションが選択されていることを確認してください。
:::
#### CI/CD プラットフォームでの署名
CI/CD プラットフォームで証明書を使用するためには、以下の手順で証明書を「[base64] 文字列」にエクスポートし、環境変数の `APPLE_CERTIFICATE` および `APPLE_CERTIFICATE_PASSWORD` を設定する必要があります:
1. 「`Keychain Access`キーチェーン・アクセス」アプリを開き、_login_ キーチェーン内の「_My Certificates_」タブをクリックして、自分の証明書のエントリを見つけます。
2. エントリを展開し、キー項目を右クリックして、「`Export "$KEYNAME"`"$KEYNAME" をエクスポート)」を選択します。
3. 証明書の「`.p12` ファイル」を保存するためのパスを選択し、エクスポートされた証明書用のパスワードを設定します。
4. ターミナルで次のスクリプトを実行して、「`.p12` ファイル」を base64 に変換します:
```sh
openssl base64 -in /path/to/certificate.p12 -out certificate-base64.txt
```
5. 「`certificate-base64.txt` ファイル」の内容を環境変数の「`APPLE_CERTIFICATE`」に設定します。
6. 証明書のパスワードを環境変数の「`APPLE_CERTIFICATE_PASSWORD`」に設定します。
<br />
<details>
<summary>GitHub Actions の設定例</summary>
必要な「シークレット」:
- `APPLE_ID` - あなたの Apple ID メール・アドレス
- `APPLE_ID_PASSWORD` - あなたの Apple ID パスワード
- `APPLE_CERTIFICATE` - base64 でエンコードされた「`.p12` ファイル」
- `APPLE_CERTIFICATE_PASSWORD` - エクスポートした「`.p12` ファイル」のパスワード
- `KEYCHAIN_PASSWORD` - あなたのキーチェーンのパスワード
「シークレットを設定する方法」については、[GitHub の公式ガイド](https://docs.github.com/jp/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) をご覧ください。
```yaml
name: 'build'
on:
push:
branches:
- main
jobs:
build-macos:
needs: prepare
strategy:
matrix:
include:
- args: '--target aarch64-apple-darwin'
arch: 'silicon'
- args: '--target x86_64-apple-darwin'
arch: 'intel'
runs-on: macos-latest
env:
APPLE_ID: ${{ secrets.APPLE_ID }}
APPLE_ID_PASSWORD: ${{ secrets.APPLE_ID_PASSWORD }}
steps:
- name: Import Apple Developer Certificate
env:
APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }}
APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }}
KEYCHAIN_PASSWORD: ${{ secrets.KEYCHAIN_PASSWORD }}
run: |
echo $APPLE_CERTIFICATE | base64 --decode > certificate.p12
security create-keychain -p "$KEYCHAIN_PASSWORD" build.keychain
security default-keychain -s build.keychain
security unlock-keychain -p "$KEYCHAIN_PASSWORD" build.keychain
security set-keychain-settings -t 3600 -u build.keychain
security import certificate.p12 -k build.keychain -P "$APPLE_CERTIFICATE_PASSWORD" -T /usr/bin/codesign
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KEYCHAIN_PASSWORD" build.keychain
security find-identity -v -p codesigning build.keychain
- name: Verify Certificate
run: |
CERT_INFO=$(security find-identity -v -p codesigning build.keychain | grep "Apple Development")
CERT_ID=$(echo "$CERT_INFO" | awk -F'"' '{print $2}')
echo "CERT_ID=$CERT_ID" >> $GITHUB_ENV
echo "Certificate imported."
- uses: tauri-apps/tauri-action@v0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }}
APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }}
APPLE_SIGNING_IDENTITY: ${{ env.CERT_ID }}
with:
args: ${{ matrix.args }}
```
</details>
## 公証(公正証書 Notarization
アプリケーションを公証するには、Tauri が Apple で認証を行なうために資格情報を提供する必要があります:
- APPLE_API_ISSUER、APPLE_API_KEY と APPLE_API_KEY_PATH 「App Store Connect API キー」を使用して認証
[App Store Connect/Users and Access のページ] を開き、「Integrations統合」タブを選択、「Add追加」ボタンをクリックして、「名前」と「Developer access開発者アクセス」を選択します。
「APPLE_API_ISSUER発行者 ID」はキー・テーブルの上側に表示され、「APPLE_API_KEY」はそのテーブルの「キー ID 列」の値です。
「private key秘密鍵」のダウンロードも必要ですが、これは一回だけ実行され、ページをリロードした後にのみ表示されますボタンが、新しく生成されたキーに対応するテーブル行にボタンが表示されます
この Private Key秘密鍵ファイルのパスは、環境変数の 「APPLE_API_KEY_PATH」を通して設定する必要があります。
- APPLE_ID、APPLE_PASSWORD と APPLE_TEAM_ID 自分の Apple ID で認証
あるいは、自分の Apple ID で認証するには、「APPLE_ID」を「Apple アカウントのメール・アドレス」に設定し、「APPLE_PASSWORD」を Apple アカウントの「[アプリ用パスワード]」に設定します。
:::note
「_Developer ID Application_」証明書を使用する場合は、「公証」が必要です。
:::
[Certificates]: https://developer.apple.com/account/resources/certificates/list
[Apple Developer]: https://developer.apple.com/jp/
[Apple App Store]: https://www.apple.com/jp/app-store/
[App Store Connect/Users and Access のページ]: https://appstoreconnect.apple.com/access/users
[`tauri.conf.json > bundle > macOS > signingIdentity`]: /reference/config/#signingidentity
[証明書署名リクエストを作成する]: https://developer.apple.com/jp/help/account/certificates/create-a-certificate-signing-request/
[Certificates, IDs & Profiles のページ]: https://developer.apple.com/account/resources/certificates/list
[アプリ用パスワード]: https://support.apple.com/ja-jp/102654
## 一時的な署名(アドホックな署名)
Apple 認証済みの「本人確認 identity」の提示は望まないが、アプリケーションへの署名は行ないたい場合は、*アドホック(一時的な)*署名を設定できます。
このやりかたは、インターネット経由のすべてのアプリに対して、コード署名を要求する ARM アーキテクチャApple Siliconデバイスで役立ちます。
:::caution
アドホック・コード署名があっても、macOS がユーザーにそのようなアプリのインストールを [ホワイトリストに登録する](https://support.apple.com/ja-jp/guide/mac-help/open-a-mac-app-from-an-unknown-developer-mh40616/mac) ように「プライバシーとセキュリティ設定」で要求することがあります。
:::
アドホック署名を設定するには、Tauri に“疑似”本人確認pseudo-identity「`-`」を指定します。すなわち:
```json
"signingIdentity": "-"
```
Tauri の「署名の本人確認」設定の詳細については、前述の [Tauri の設定](#tauri-の設定) の項を参照してください。
[Base64] https://ja.wikipedia.org/wiki/Base64
<div style="text-align: right;">
【※ この日本語版は、「Jun 6, 2025 英語版」に基づいています】
</div>

View File

@@ -0,0 +1,366 @@
---
title: Windows でのコード署名
sidebar:
label: Windows
order: 12
i18nReady: true
---
import { Steps } from '@astrojs/starlight/components';
import TranslationNote from '@components/i18n/TranslationNote.astro';
アプリケーションを [Microsoft Store] に掲載し、ブラウザーからダウンロードしたときに「このアプリケーションは信頼されていないため起動できません」という [SmartScreen] 警告が表示されないようにするためには、Windows でのコード署名が必要です。
エンド・ユーザーが [SmartScreen] 警告を気にしないとか、ブラウザー経由でダウンロードしていない場合では、アプリケーションを Windows 上で実行するために Windows のコード署名は必要はありません。
この章では、「OV 証明書」(「組織検証 Organization Validation」証明書と「[Azure Key Vault](#azure-key-vault)」による署名について説明します。
もしあなたがここに記載されていない他の署名方式、たとえば「EV 証明書」(「拡張検証 Extended Validation」証明書などを使用する場合は、証明書発行者の公式文書を確認し、下記の [カスタム署名コマンド](#独自の署名コマンド) の項を参照してください。
<TranslationNote lang="ja">
**デジタル証明書** インターネットでデータを暗号化して通信を行なうためのプロトコルSSL/TSLにおいて用いられる「SSL サーバー証明書」。以下の三種類があります。
- ドメイン検証 Domain ValidationDV
- 組織検証 Organization ValidationOV
- 拡張検証 Extended ValicationEV
</TranslationNote>
## OV 証明書
:::danger
この章は、2023 年 6 月 1 日以前に取得された「OV コード署名証明書」にのみ適用されます。それ以降に取得した「EV 証明書」および「OV 証明書」によるコード署名については、証明書発行元の公式文書を参照してください。
:::
:::note
「EV 証明書」を使用してアプリに署名すると、Microsoft SmartScreen で直ちに評価され、ユーザーへの警告は表示されなくなります。
もし「OV 証明書」を選択した場合これは通常安価で個人でも利用できるものですがでも、Microsoft SmartScreen はユーザーがアプリをダウンロードするときに警告を表示します。その証明書が十分な評価を確立するまでには、しばらく時間がかかる場合があります。Microsoft に [アプリを提出] し、人力に拠るレビューを依頼してもよいかもしれません。保証はありませんが、アプリに悪意のあるコードが含まれていない場合、Microsoft は追加の評価を付与し、アップロードされたファイルに対する警告が削除される可能性はあります。
「OV 証明書」と「EV 証明書」の詳細については、[各 SSL 証明書の比較](https://www.digicert.com/ja/difference-between-dv-ov-and-ev-ssl-certificates) を参照してください。
:::
### 事前準備(必要なもの)
- Windows - 他のプラットフォームを使用することもできますが、このチュートリアルでは Powershell のネイティブ機能を使用します。
- 動作する Tauri アプリケーション
- コード署名証明書 - [Microsoft 社の文書] に記載されているサービスからコード署名証明書は入手できます。「EV 証明書」以外のものについては、リストに記載されているところ以外にも認証局が存在する可能性がありますので、ご自身で比較検討の上、ご自身の責任において選択してください。
- 必ず「**コード署名証明書**」のほうを取得してください。「SSL 証明書」では **機能しません!**
### 作業手順
Windows でコード署名の準備をするには、いくつか作業が必要です。これには、証明書を特定の形式に変換し、その証明書をインストールし、証明書から必要な情報をデコードすることが含まれます。
<Steps>
1. #### `.cer` ファイルを `.pfx` ファイルに変換
- この作業には以下のものが必要です:
- 「証明書ファイル」(たとえばファイル名「`cert.cer`」のような)
- 「秘密鍵ファイル」(たとえばファイル名「`private-key.key`」のような)
- コマンド・プロンプトを開き、コマンド「`cd Documents/Certs`」を使用して現在のディレクトリに移動します。
- 次のコマンド「`openssl pkcs12 -export -in cert.cer -inkey private-key.key -out certificate.pfx`」を使用して `.cer` ファイルを `.pfx` ファイルに変換します。〔《訳注》コマンド内のファイル名「`cert.cer`」「`private-key.key`」部分は自分の証明書/秘密鍵のファイル名に変更する必要があります。〕
- エクスポート用パスワード入力を求めるメッセージが表示されるはずです。ここで入力したパスワードを**忘れないでください!**
2. #### `.pfx` ファイルをキーストアにインポート
- つぎに、「`.pfx` ファイル」をインポートします。
- 「`$WINDOWS_PFX_PASSWORD = 'MYPASSWORD'`」を使い上記の「エクスポート用パスワード」をこの変数に割り当てます〔《訳注》`MYPASSWORD` 部分に「エクスポート用パスワード」を入力〕。
- そして、次のコマンド「`Import-PfxCertificate -FilePath certificate.pfx -CertStoreLocation Cert:\CurrentUser\My -Password (ConvertTo-SecureString -String $WINDOWS_PFX_PASSWORD -Force -AsPlainText)`」を使用して証明書をインポートします。
3. #### 変数の準備
- スタート・メニュー ➡️「`certmgr.msc`」と入力すると、「個人証明書マネージャー」が起動し、そこから「PersonalCertificates個人証明書」を開きます。
- 先ほどインポートした証明書を見つけてダブルクリックし、「Details詳細」タブをクリックします。
- 署名ハッシュ・アルゴリズムハッシュ関数は、Tauri 製?の「`digestAlgorithm`」になります。(ヒント: このアルゴリズムはおそらく `sha256` 関数です)
- 「Thumbprint」までスクロールダウンしてください。「A1B1A2B2A3B3A4B4A5B5A6B6A7B7A8B8A9B9A0B0」のような値があるはずです。これが「certificateThumbprint証明書の指紋」です。
- 「タイムスタンプ URL」も必要です。これは証明書の署名時刻を確認するためのタイムサーバーです。筆者の場合は「http://timestamp.comodoca.com」を使用していますが、証明書の取得元にもタイムスタンプ URL があるはずです。
</Steps>
### `tauri.conf.json` ファイルの準備
1. これで、`certificateThumbprint`、`digestAlgorithm`、`timestampUrl` が準備できたので、`tauri.conf.json` ファイルを開きます。
2. `tauri.conf.json` ファイルでは、`tauri` -> `bundle` -> `windows` と辿って `windows` の項を探してください。取得した情報を格納する変数が三つあります。以下のように記述してください。
```json tauri.conf.json
"windows": {
"certificateThumbprint": "A1B1A2B2A3B3A4B4A5B5A6B6A7B7A8B8A9B9A0B0",
"digestAlgorithm": "sha256",
"timestampUrl": "http://timestamp.comodoca.com"
}
```
3. 保存して、`tauri build` を実行します。
4. コンソール出力には以下の内容が表示されます。
```
info: signing app
info: running signtool "C:\\Program Files (x86)\\Windows Kits\\10\\bin\\10.0.19041.0\\x64\\signtool.exe"
info: "Done Adding Additional Store\r\nSuccessfully signed: アプリケーションのファイル・パスがここに表示されます
```
これは、`.exe` ファイルが正常に署名されたことを示しています。
以上で、Tauri アプリケーションが Windows 署名用に正常にセットアップできました。
### GitHub Actions を使用してアプリケーションに署名
GitHub Actions を使用してアプリケーションに署名するワークフローを作成することもできます。
#### GitHub のシークレット機能
GitHub Action を適切に設定するために、「GitHub シークレット」をいくつか追加する必要があります。このシークレットには任意の名前を付けることができます。
<TranslationNote lang="ja">
**シークレット** secrets organization、リポジトリ、またはリポジトリ環境の GitHub Actions ワークフローで使うために作成する変数。〔[GitHub Docs](https://docs.github.com/ja/actions/security-for-github-actions/security-guides/about-secrets)
</TranslationNote>
- GitHub シークレットを追加する方法については、GitHub Docs の[シークレットの作成] ガイドをご覧ください。
使用する「シークレット」は次のとおりです:
| GitHub シークレット | 変数の値 |
| :--------------------------: | :-----------------------------------------------------------------------------------------------------------------------------: |
| WINDOWS_CERTIFICATE | 「.pfx 証明書」の Base64 エンコード版は、次のコマンドを使用して生成できます: `certutil -encode certificate.pfx base64cert.txt` |
| WINDOWS_CERTIFICATE_PASSWORD | 「certificate.pfx」の作成時に使用する証明書エクスポート・パスワード |
#### ワークフローの変更
1. ワークフローに、「証明書」を Windows 環境にインポートするためのステップを追加する必要があります。このワークフローでは、以下の処理が実行されます。
1. 「GitHub シークレット」を環境変数に割り当て
2. 新しい `certificate` ディレクトリの作成
3. `WINDOWS_CERTIFICATE` を「tempCert.txt」にインポート
4. `certutil` コマンドを使用して「tempCert.txt」を base64 から `.pfx` ファイルにデコード
5. 「tempCert.txt」を削除
6. `.pfx` ファイルを Windows レジストリ内の「証明書ストア」(証明書格納エリア)へインポートし `WINDOWS_CERTIFICATE_PASSWORD` を安全な文字列へ変換後、その文字列をインポート・コマンドで利用
2. [`tauri-action` publish テンプレート]を使用します。
```yml
name: 'publish'
on:
push:
branches:
- release
jobs:
publish-tauri:
strategy:
fail-fast: false
matrix:
platform: [macos-latest, ubuntu-latest, windows-latest]
runs-on: ${{ matrix.platform }}
steps:
- uses: actions/checkout@v2
- name: setup node
uses: actions/setup-node@v1
with:
node-version: 12
- name: install Rust stable
uses: actions-rs/toolchain@v1
with:
toolchain: stable
- name: install webkit2gtk (ubuntu only)
if: matrix.platform == 'ubuntu-latest'
run: |
sudo apt-get update
sudo apt-get install -y webkit2gtk-4.0
- name: install app dependencies and build it
run: yarn && yarn build
- uses: tauri-apps/tauri-action@v0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tagName: app-v__VERSION__ # このアクションは自動的に \_\_VERSION\_\_ をアプリのバージョンで置き換えます
releaseName: 'App v__VERSION__'
releaseBody: 'See the assets to download this version and install.'
releaseDraft: true
prerelease: false
```
1. `-name: install app dependencies and build it` 項目の直前に次のステップを追記します。
```yml
- name: import windows certificate
if: matrix.platform == 'windows-latest'
env:
WINDOWS_CERTIFICATE: ${{ secrets.WINDOWS_CERTIFICATE }}
WINDOWS_CERTIFICATE_PASSWORD: ${{ secrets.WINDOWS_CERTIFICATE_PASSWORD }}
run: |
New-Item -ItemType directory -Path certificate
Set-Content -Path certificate/tempCert.txt -Value $env:WINDOWS_CERTIFICATE
certutil -decode certificate/tempCert.txt certificate/certificate.pfx
Remove-Item -path certificate -include tempCert.txt
Import-PfxCertificate -FilePath certificate/certificate.pfx -CertStoreLocation Cert:\CurrentUser\My -Password (ConvertTo-SecureString -String $env:WINDOWS_CERTIFICATE_PASSWORD -Force -AsPlainText)
```
4. 保存して自分のリポジトリにプッシュします。
5. これで、あなたのワークフローで Windows 証明書を GitHub ランナーにインポートできるようになり、自動コード署名が可能になります。
## Azure Key Vault
[Azure Key Vault] 証明書と資格情報を提示することで、Windows 実行可能ファイルに署名できます。
:::note
ここの説明では、「シークレット」ベースの認証をサポートしている [relic] ツールを使用しますが、必要に応じて代替ツールを設定することもできます。
「relic」をダウンロードするには、[relic のリリース・ページ] を確認するか、`go install github.com/sassoftware/relic/v8@latest` を実行してください。
:::
1. Key Vaultキー・コンテナー鍵保管庫
[Azure Portal] で [Key vaults service] に移動し、「Create作成」ボタンをクリックして新しい「Key Vaultキー・コンテナー」を作成します。
「キー・コンテナー名」Key Vault nameを覚えておいてください。「証明書 URL」の設定で登録が必要になります。
<TranslationNote lang="ja">
**Key Vault** キー・コンテナー。原意は「鍵の保管庫キー・ヴォルト」ですが、Microsoft 社の[日本語サイト](https://learn.microsoft.com/ja-jp/azure/key-vault/general/quick-create-portal) では「キー・コンテナー」と記載されていますので、その表記に倣います。
</TranslationNote>
2. Certificate証明書
「キー・コンテナー」を作成したら、そのキー・コンテナーを選択し、「オブジェクト Object > 証明書 Certificates」ページに移動して新しい証明書を作成し、「生成 Generate /インポート Import」ボタンをクリックします。
「証明書名」Certificate nameは覚えておいてください。「証明書 URL」の設定で登録が必要になります。
3. Tauri の設定
[relic] は設定ファイルで、どの「署名キー」を使用すべきかを判定しています。Azure Key Vault では、「証明書の URL」も必要になります。
`src-tauri` フォルダに「`relic.conf` ファイル」を作成し、自分の証明書を使用するように relic を設定します:
```yml title=src-tauri/relic.conf
tokens:
azure:
type: azure
keys:
azure:
token: azure
id: https://\<KEY_VAULT_NAME\>.vault.azure.net/certificates/\<CERTIFICATE_NAME\>
```
《注意》 \<KEY_VAULT_NAME\>(キー・コンテナー名)の部分と \<CERTIFICATE_NAME\>(証明書名)の部分は前述の手順でメモした「適切な名前」に置き換える必要があることに注意してください。
署名時に Azure Key Vault の設定を使用するように Tauri を設定するには、[bundle > windows > signCommand] の設定値を変更します:
```json title=tauri.conf.json
{
"bundle": {
"windows": {
"signCommand": "relic sign --file %1 --key azure --config relic.conf"
}
}
}
```
4. 資格情報 Credentials
[relic] では「証明書」を読み込むために Azure で認証を行なう必要があります。
「Azure portal」のランディング・ページで、「[Microsoft Entra 管理センター]」(旧称 Azure Active Directoryに移動し、サイド・メニューから「管理 Manage > アプリの登録 App registrations」ページに進みます。
「新規登録 New registration」をクリックして新しいアプリを作成します。アプリが作成されると「アプリケーションの詳細」ページにリダイレクトされ、そこで「アプリケーションクライアントID」と「ディレクトリテナントID」を確認できます。
この二つの ID をそれぞれ環境変数の `AZURE_CLIENT_ID` と `AZURE_TENANT_ID` に設定します。
サイド・メニューの「管理 Manage > 証明書とシークレット Certificates & secrets」で「新しいクライアント・シークレット New client secret」ボタンをクリックし、「値 Value」列の文字列を環境変数 `AZURE_CLIENT_SECRET` の値として設定します。
すべての資格情報を設定したら、「キー・コンテナー」のページに戻り、「アクセス制御IAM」ページに移動します。
新しく作成したアプリケーションに、「Key Vault 証明書ユーザー」および「Key Vault 暗号化ユーザー」という[ロールを割り当てる]必要があります。
こうしたすべての変数を設定した後、`tauri build` を実行すると、署名された Windows インストーラーが生成されます。
## 独自の署名コマンド
上述の [Azure Key Vault](#azure-key-vault) の項では、強力な Tauri Windows 署名設定を利用して、Tauri CLI が Windows インストーラー実行可能ファイルに署名する特別なシェル・コマンドを使用するようにしました。
「[bundle > windows > signCommand] 設定のオプションを用いると、Windows 実行可能ファイルに署名できる「コード署名ツール」ならどれでも利用できるようになります。
:::tip
Linux および macOS マシンから Windows インストーラーをクロスコンパイルする場合は、デフォルトの実装のコマンドが Windows マシンのみで機能するため、「独自の署名コマンド」を **使用する必要があります**。
:::
[Azure Portal]: https://portal.azure.com
[Key vaults service]: https://portal.azure.com/#browse/Microsoft.KeyVault%2Fvaults
[Microsoft 社の文書]: https://learn.microsoft.com/ja-jp/windows-hardware/drivers/dashboard/code-signing-cert-manage
[アプリを提出]: https://www.microsoft.com/en-us/wdsi/filesubmission/
[シークレットの作成]: https://docs.github.com/ja/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions
[`tauri-action` publish テンプレート]: https://github.com/tauri-apps/tauri-action
[relic]: https://github.com/sassoftware/relic
[relic のリリース・ページ]: https://github.com/sassoftware/relic/releases/
[bundle > windows > signCommand]: /reference/config/#signcommand
[SmartScreen]: https://en.wikipedia.org/wiki/Microsoft_SmartScreen
[Microsoft Store]: https://apps.microsoft.com/
## Azure コード署名
「Azure コード署名証明書」と「資格情報」を提供することで、Windows 実行ファイルに署名できます。Azureコード署名アカウントをまだお持ちでない場合は、こちらの [チュートリアル(英語版)](https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/) をご覧ください。
### 事前準備
Github Actions で署名を行なう場合は、以下のすべてをインストールする必要があります。
1. [信頼済み署名アカウント](https://learn.microsoft.com/ja-jp/azure/trusted-signing/quickstart?tabs=registerrp-portal,account-portal,certificateprofile-portal,deleteresources-portal) および アクセス権限が設定されていること
1. [.NET](https://dotnet.microsoft.com/ja-jp/download/dotnet/8.0) .NET 6 またはそれ以降を推奨)
1. [Azure CLI](https://learn.microsoft.com/ja-jp/cli/azure/install-azure-cli-windows?tabs=azure-cli#install-or-update)
1. [Signtool署名ツール](https://learn.microsoft.com/ja-jp/dotnet/framework/tools/signtool-exe) Windows 11 SDK 10.0.22000.0 またはそれ以降を推奨)
### 作業手順
[trusted-signing-cli](https://github.com/Levminer/trusted-signing-cli)(信頼済み署名 CLIをインストールし、環境変数を設定する必要があります。
<Steps>
1. #### trusted-signing-cli のインストール
- `cargo install trusted-signing-cli`
2. #### 環境変数の設定
- trusted-signing-cli では、以下の環境変数を設定する必要があり、どの項目も「Github Actions [シークレット](https://docs.github.com/ja/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions)」として追加することを忘れないでください:
- `AZURE_CLIENT_ID` [アプリの登録](https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/#step-4-create-app-registration-user-credentials) での「アプリケーション IDクライアント ID」です。
- `AZURE_CLIENT_SECRET` [アプリの登録](https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/#step-4-create-app-registration-user-credentials)」での「クライアント・シークレット」値のことです。
- `AZURE_TENANT_ID` 「Azure ディレクトリ」の「テナント ID」のことです。これは、「[アプリの登録](https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/#step-4-create-app-registration-user-credentials)」からも入手できます。
3. ### `tauri.conf.json` ファイルの修正
- すでに作成済みの `tauri.conf.json` ファイルを修正するか、Windows 用の専用設定ファイルを作成します。「URL」と「証明書名」は自分のアプリ用の値に置き換えます。
- -e Azure コード署名アカウントのエンドポイント
- -a Azure コード署名アカウントの名前
- -c Azure コード署名アカウント内の証明書プロファイルの名前
- -d 署名されたコンテンツの説明オプション。「.msi インストーラー」に署名する場合は、この記載内容が「UAC プロンプト」にインストーラー名として表示されます。設定されていない場合は、ランダムな文字列が表示されます。
{' '}
<TranslationNote lang="ja">
**UAC プロンプト** Windows の「ユーザー・アカウント制御User Account
Control機能」が管理者権限を必要とする操作を実行する際に表示する確認画面。[参考](https://learn.microsoft.com/ja-jp/windows-server/security/user-account-control/how-user-account-control-works)
</TranslationNote>
```json title=tauri.conf.json
{
"bundle": {
"windows": {
"signCommand": "trusted-signing-cli -e https://wus2.codesigning.azure.net -a MyAccount -c MyProfile -d MyApp %1"
}
}
}
```
</Steps>
[Azure Key Vault]: https://learn.microsoft.com/ja-jp/azure/key-vault/general/overview
[Microsoft Entra 管理センター]: https://learn.microsoft.com/ja-jp/entra/identity-platform/howto-create-service-principal-portal
[ロールを割り当てる]: https://learn.microsoft.com/ja-jp/azure/key-vault/general/rbac-guide?tabs=azure-cli#azure-built-in-roles-for-key-vault-data-plane-operations
<div style="text-align: right;">
【※ この日本語版は、「Mar 3, 2025 英語版」に基づいています】
</div>

View File

@@ -58,7 +58,7 @@ Tauriの「`resources` 機能」(「[追加ファイルの埋め込み](/ja/de
Tauri が使用している AppImage ツールの「`linuxdeploy`」は、現在 ARM AppImage との[クロスコンパイルをサポートしていません]。つまり、ARM AppImage は ARM デバイス上またはエミュレータ上でのみビルドが可能となります。
アプリをビルドするためにエミュレーション環境の「QEMU」を利用するワークフローの事例については、[GitHub Action 設定ガイド](/ja/distribute/pipelines/github/#arm-runner-compilation) の章をご覧ください。ただし、この処理は非常に遅いため、Build Minutesビルド時間が無料のパブリック・リポジトリでのみ推奨されます。プライベート・リポジトリでは、GitHub の「ARM ランナー」(上記リンク)の方がコスト効率が良く、セットアップもはるかに簡単です。
アプリをビルドするためにエミュレーション環境の「QEMU」を利用するワークフローの事例については、[GitHub Action 設定ガイド](/ja/distribute/pipelines/github/#arm-ランナーによるコンパイル) の章をご覧ください。ただし、この処理は非常に遅いため、Build Minutesビルド時間が無料のパブリック・リポジトリでのみ推奨されます。プライベート・リポジトリでは、GitHub の「ARM ランナー」(上記リンク)の方がコスト効率が良く、セットアップもはるかに簡単です。
<TranslationNote lang="ja">