Git Security: Signed Commits and GPG Key Best Practices Quiz

Assess your understanding of Git security by exploring concepts like signed commits, GPG keys, and their role in maintaining code integrity and author authenticity. This quiz aims to deepen your knowledge of secure workflows and the tools used to safeguard repository contributions.

1. Purpose of Signed Commits

   Why are signed commits important in a collaborative Git workflow involving multiple contributors?

   1. They verify the identity of the commit author and prevent unauthorized changes.
   2. They reduce the repository size by compressing commits.
   3. They automatically merge branches without conflicts.
   4. They increase repository cloning speed.

   Explanation: Signed commits ensure that the author of each commit can be reliably verified, making it significantly harder for unauthorized users to inject malicious code unnoticed. The other options do not address the core purpose of signed commits: repository size, merge conflicts, and cloning speed are unrelated to commit signatures. Signed commits focus on authenticity and integrity, not performance or merging functionality.

2. Generating a GPG Key

   Which command best describes how to generate a new GPG key pair for use with Git commit signing?

   1. gpg --full-generate-key
   2. git keygen --generate-keypair
   3. gpg-sign --create-key
   4. git gpg --new-key

   Explanation: The correct command to generate a new GPG key pair is 'gpg --full-generate-key', which creates a public/private key pair suitable for signing. The command 'git keygen --generate-keypair' is incorrect and does not exist, and 'gpg-sign --create-key' is not valid syntax. Similarly, 'git gpg --new-key' is not part of standard Git functionality. Only the first option accurately creates a GPG key pair.

3. Verifying a Signed Commit

   After pulling new commits, how can you check if a commit is properly signed and verified when using Git on the command line?

   1. git log --show-signature
   2. git status --verify-signatures
   3. git check-signed --commit
   4. git commits --validate-key

   Explanation: To see signatures and their verification status, you should use 'git log --show-signature', which displays signature information for each commit. The command 'git status --verify-signatures' is invalid since status does not check signatures. 'git check-signed --commit' and 'git commits --validate-key' are not recognized Git commands. Only the first option provides the needed signature verification.

4. Trust and Revocation of GPG Keys

   What is a potential security risk if a developer’s GPG private key used for signing commits is accidentally exposed?

   1. Others could forge commits as that developer, compromising repository trust.
   2. The Git repository will stop accepting unsigned commits.
   3. It will automatically delete the developer's repository.
   4. Branches will be locked and require manual unlocking.

   Explanation: If a private key is leaked, anyone with access can sign commits claiming to be the developer, undermining the integrity of the commit history. The repository does not refuse unsigned commits or delete itself automatically in this scenario. Branches are also not locked due to key compromise alone. The key risk is impersonation through forged signatures.

5. Associating a GPG Key with Git

   When configuring Git to sign commits with your GPG key, which Git configuration setting must be set to the key’s ID?

   1. user.signingkey
   2. commit.gpgkey
   3. gpg.keyid
   4. user.keygen

   Explanation: You must set the 'user.signingkey' configuration to your GPG key’s ID so Git knows which key to use for signing commits. The setting 'commit.gpgkey' does not exist, and 'gpg.keyid' is not a recognized Git configuration. 'user.keygen' is used for generating keys, not for specifying which one to use. Only 'user.signingkey' is correct.