バイナリ静的ライブラリ依存関係

SE-0305 で導入された Artifact Bundle に、新しいアーティファクト種別 staticLibrary を追加し、C インターフェースを公開する静的ライブラリを非 Apple プラットフォームでも配布できるようにします。あわせて、配布されるバイナリが対象プラットフォームで安全に使えるかを検証するための監査ツールを導入します。

本 Proposal のスコープは「C 標準ライブラリと C ランタイム以外に依存しない、C インターフェースの静的ライブラリ」です。Swift の静的ライブラリや動的ライブラリの配布は今後の課題として残されています。

staticLibrary アーティファクト

Artifact Bundle のマニフェスト（info.json）に、新しい type: "staticLibrary" を指定できるようになります。各バリアントには、リンク対象のライブラリファイル本体に加えて、Swift / C コードから API を利用するために必要なヘッダ検索パスとモジュールマップを記述します。

• path: アーティファクトバンドルのルートからの相対パス。Apple / Linux では .a、Windows では .lib ファイルを指します。
• supportedTriples: そのバリアントが対応するターゲットトリプルのリスト。
• staticLibraryMetadata.headerPaths: ヘッダが置かれたディレクトリのリスト。Swift / C コンパイラへ通常のヘッダ検索パスとして渡されます。
• staticLibraryMetadata.moduleMapPath: モジュールマップへのパス。Swift コードから import したい場合は必須です。

マニフェストの例は次のようになります（Linux aarch64 向けの例）。

{
    "schemaVersion": "1.0",
    "artifacts": {
        "example": {
            "type": "staticLibrary",
            "version": "1.0.0",
            "variants": [
                {
                    "path": "libExample.a",
                    "supportedTriples": ["aarch64-unknown-linux-gnu"],
                    "staticLibraryMetadata": {
                        "headerPaths": ["include"],
                        "moduleMapPath": "include/example.modulemap"
                    }
                }
            ]
        }
    }
}

パッケージ側は、これまでの binaryTarget と同じように、このアーティファクトバンドルを指す binaryTarget を Package.swift に記述することで依存として利用できます。

監査ツールによるバイナリの安全性チェック

静的ライブラリが C 標準ライブラリ以外の未解決シンボルを抱えていると、利用者のプラットフォームでリンクや実行が壊れる可能性があります。これを配布前にチェックするため、ツールチェインに llvm-objdump を同梱し、それを利用する監査ツールが新たに提供されます。

監査ツールの動作は次のような流れです。

• 静的ライブラリ内の各オブジェクトファイルを llvm-objdump で走査し、Mach-O（Apple）／ELF（Linux）／COFF（Windows）いずれのフォーマットでも、リロケーション情報から「定義されたシンボル」と「参照されているシンボル」の一覧を構築します。
• 同時に C コンパイラからデフォルトのリンカ起動コマンドを引き出し、C プログラムが何もしなくてもリンクされる標準ライブラリ群を特定します。それらも走査して「定義されたシンボル」集合に加えます。
• 参照シンボルの集合が定義シンボルの集合の部分集合になっていなければ、エラーを報告します。

Linux については、Python コミュニティの manylinux と同様の発想で、サポート対象の中で最も古い glibc を持つ Docker イメージを提供し、その中で監査を実行する運用が想定されています。glibc は後方互換なので、古い glibc に対して通るバイナリは新しい glibc でも動く、という形で実行時の互換性を保証します。

なお、アーティファクトの配布範囲が限定されていて、すべての利用パッケージが把握できているような状況では、追加の C ライブラリ依存を持つアーティファクトを配ること自体は禁じられていません。ただしその場合、利用側のターゲットが必要な依存ライブラリを明示的に自分で持ち込む必要があります。

セキュリティ上の注意

本提案は、SE-0272 で挙げられていたバイナリ依存のセキュリティ上の懸念（アーティファクト配布サーバと Package Manifest を管理するリポジトリの両方を攻撃者に掌握されると、悪意あるライブラリを差し込まれる可能性がある）を、そのまま非 Apple プラットフォームにも持ち込みます。バイナリ依存を導入する際は、ソース依存以上に配布元の信頼性を確認する必要があります。

既存パッケージへの影響

既存のパッケージには影響しません。この変更は SwiftPM の機能を純粋に追加するものであり、既存の Apple プラットフォーム向け XCFramework の扱いは変わりません。