GitLab UIからの署名されたコミット
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed、GitLab Dedicated
この機能の利用可否は、機能フラグによって制御されます。詳細については、履歴を参照してください。この機能はテストには利用できますが、本番環境での使用には適していません。
GitLabユーザーインターフェースを使用してコミットを作成すると、コミットが直接プッシュされることはありません。代わりに、コミットはお客様の代わりに行われます。
これらのコミットに署名するために、GitLabはインスタンスに設定されたグローバルキーを使用します。GitLabはあなたのプライベートキーにアクセスできないため、作成されたコミットはあなたのアカウントに関連付けられたキーを使用して署名できません。
たとえば、ユーザーAがユーザーBが作成した提案を適用する場合、コミットには次のものが含まれます:
Author: User A <a@example.com>
Committer: GitLab <noreply@gitlab.com>
Co-authored-by: User B <b@example.com>前提要件
GitLab UIコミットのコミット署名を使用する前に、構成する必要があります。
コミットのコミッターフィールド
Gitでは、コミットには作成者とコミッターの両方がいます。Webコミットの場合、Committerフィールドは設定可能です。このフィールドを更新するには、GitLab UIコミットのコミット署名の構成を参照してください。
GitLabは、Committerフィールドがコミットを作成するユーザーに設定されていることに依存する複数のセキュリティ機能を提供します。例:
- プッシュルール:(
Reject unverified usersまたはCommit author's email)。 - マージリクエスト承認の防止。
コミットがインスタンスによって署名されると、GitLabはこれらの機能のためにAuthorフィールドに依存します。
REST APIを使用して作成されたコミット
REST APIを使用して作成されたコミットも、Webベースのコミットと見なされます。REST APIエンドポイントを使用すると、コミットのauthor_nameフィールドとauthor_emailフィールドを設定できます。これにより、他のユーザーの代わりにコミットを作成できます。
コミット署名が有効になっている場合、REST APIリクエストを送信するユーザーとは異なるauthor_nameとauthor_emailを持つREST APIを使用して作成されたコミットは拒否されます。
トラブルシューティング
Webコミットは、リベース後に署名されなくなります
以前に署名されたブランチ内のコミットは、次の場合に署名されなくなります:
- コミット署名は、GitLab UIから作成されたコミットに対して構成されています。
- マージリクエストは、GitLab UIからリベースされます。
これは、以前のコミットが変更され、ターゲットブランチの上に追加されるために発生します。GitLabはこれらのコミットに署名できません。
この問題を回避するには、ブランチをローカルでリベースし、変更をGitLabにプッシュして戻します。