diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index f5634d058..c9c8556bd 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -45,6 +45,10 @@ }, "postCreateCommand": "bash .devcontainer/post-create.sh", + // Unlike postCreateCommand, this runs on every attach, not just the first. + // Forwarded agent sockets are per-session, so anything that depends on one + // (see post-start.sh) has to be re-checked here. + "postStartCommand": "bash .devcontainer/post-start.sh", "customizations": { "vscode": { diff --git a/.devcontainer/post-create.sh b/.devcontainer/post-create.sh index cc3412c05..950a0c527 100755 --- a/.devcontainer/post-create.sh +++ b/.devcontainer/post-create.sh @@ -135,6 +135,4 @@ Ready, on Node $(node -v). In fish, \`nvm use\` reads .nvmrc. Switching there affects that session only; the container baseline stays on the version package.json pins. - -To sign commits: git config --global commit.gpgsign true EOF diff --git a/.devcontainer/post-start.sh b/.devcontainer/post-start.sh new file mode 100755 index 000000000..2f722dd03 --- /dev/null +++ b/.devcontainer/post-start.sh @@ -0,0 +1,91 @@ +#!/usr/bin/env bash +# ------------------------------------------------------------------------------ +# Copyright (c) The OpenINF Authors & Friends. All rights reserved. +# License: MIT OR Apache-2.0 OR BlueOak-1.0.0 +# ------------------------------------------------------------------------------ +# +# Runs on every container start/attach, not just the first. Agent forwarding +# is per-session -- VS Code opens a fresh SSH_AUTH_SOCK each time it attaches +# -- so anything that depends on it belongs here rather than in +# post-create.sh, which never runs again after the container is built. + +set -uo pipefail + +# Under gpg.format=ssh, `git commit -S` shells out to +# `ssh-keygen -Y sign -f ...`, which reads that file for the +# public key and then asks the running agent (SSH_AUTH_SOCK) to sign with the +# matching private key. VS Code forwards the agent itself but, per +# https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials, +# never copies key files into the container -- so a signingkey path copied +# verbatim from the host's gitconfig points at a file that has never existed +# here, and signing fails with "Couldn't load public key ...: No such file or +# directory" no matter how many times post-create.sh's `commit.gpgsign true` +# hint is followed. +# +# That copied path is also, almost always, a path this container's non-root +# user cannot create: a Mac's /Users/ or a Linux host's /home/ +# both live under a root-owned directory the container's `node` user has no +# write access to, so a bare `mkdir -p` on the host's literal path fails with +# EACCES regardless of host OS. So this retargets `user.signingkey`, in the +# container's own copy of the gitconfig only, at a path under $HOME that +# `node` actually owns, and writes the forwarded public key there instead of +# trying to recreate the host's path byte-for-byte. +# +# If the forwarded agent is holding exactly one identity, write it out so that +# path resolves. This can't sign with the wrong key even if it guessed wrong: +# the actual signature still goes through the agent, keyed by fingerprint, so +# a mismatched file just makes ssh-keygen report no matching identity instead +# of silently mis-signing. +if [ "$(git config --global gpg.format 2>/dev/null || true)" = "ssh" ]; then + signingkey="$(git config --global user.signingkey 2>/dev/null || true)" + if [ -n "${signingkey}" ]; then + container_signingkey="${HOME}/.ssh/$(basename "${signingkey}")" + if [ ! -f "${container_signingkey}" ]; then + identities="$(ssh-add -L 2>/dev/null || true)" + count="$(printf '%s\n' "${identities}" | grep -c '^ssh-' || true)" + if [ "${count}" -eq 1 ]; then + mkdir -p -m 700 "$(dirname "${container_signingkey}")" + printf '%s\n' "${identities}" >"${container_signingkey}" + chmod 644 "${container_signingkey}" + else + echo "==> Commit signing NOT ready: forwarded SSH agent has ${count} identities, need exactly 1 to write ${container_signingkey}" >&2 + fi + fi + if [ -f "${container_signingkey}" ]; then + if [ "${signingkey}" != "${container_signingkey}" ]; then + git config --global user.signingkey "${container_signingkey}" + fi + + # Signing and verifying are separate switches, and leaving the second one + # off makes the first one look broken. With only the above, `git commit + # -S` really does produce a signature -- `git cat-file commit HEAD` shows + # the `BEGIN SSH SIGNATURE` header -- but `git log --show-signature` + # answers: + # + # error: gpg.ssh.allowedSignersFile needs to be configured and exist + # for ssh signature verification + # No signature + # + # ssh-format verification needs a file mapping principals to the keys + # they may sign with, and Git ships no default location for one, so the + # verifier cannot run at all. `No signature` is it reporting that -- not + # a report about the commit, which is signed. Read as the latter, it + # sends you back to re-check signing settings that were correct the whole + # time, so write the file rather than leave that trap set. + email="$(git config --global user.email 2>/dev/null || true)" + if [ -n "${email}" ]; then + allowed_signers="${HOME}/.ssh/allowed_signers" + # Fields 1 and 2 only: `ssh-add -L` ends each line with the key's + # comment, and the allowed-signers grammar has no slot for one. + printf '%s %s\n' "${email}" \ + "$(awk '{print $1, $2}' "${container_signingkey}")" \ + >"${allowed_signers}" + git config --global gpg.ssh.allowedSignersFile "${allowed_signers}" + else + echo "==> Signature verification NOT configured: no user.email to attribute ${container_signingkey} to" >&2 + fi + + echo "==> Commit signing ready (${container_signingkey}, from forwarded SSH agent)" + fi + fi +fi diff --git a/collections/_docs/agent-forwarding.md b/collections/_docs/agent-forwarding.md index 4cd9253b6..b1edd61c9 100644 --- a/collections/_docs/agent-forwarding.md +++ b/collections/_docs/agent-forwarding.md @@ -3,299 +3,250 @@ title: OpenINF Next-Gen Guidance on Agent Forwarding category: contributing permalink: /docs/dev/internals/contributing/agent-forwarding/ relevant_urls: - - https://github.com/OpenINF/docker-fisher/issues/5 # psusan + auth awkwardness - - https://dev.gnupg.org/T3883 # Win32-OpenSSH support for gpg-agent's ssh-agent + - https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials + - https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification toc: true draft: true --- -Additional setup procedures may be necessary for the chosen few who hold core -OpenINF membership to sign any potential Git commits or tags. This guide will be -especially relevant for those developing inside the container provided as there -will likely be snafus to overcome before connecting to the devcontainer. +Core OpenINF members who sign their commits or tags need a couple of things +forwarded from the host into the devcontainer: a running SSH or GPG agent, and, +for SSH-format signing, a public key file. This guide covers how that forwarding +works today and what to do when it doesn't. + +The devcontainer changed substantially in [#1775][]: it no longer runs its own +`sshd` on a forwarded port, and there is no more `vscode` user or manual +`RemoteForward` tunnel to configure. Everything below reflects that container. +If you find instructions elsewhere -- including an old revision of this file -- +mentioning port 2222 or a `gpgtunnel` SSH host, they predate that change and no +longer apply. + +## How forwarding works here + +VS Code (and compatible tools like the Dev Containers CLI) forwards your +_running_ SSH agent into the container automatically; no devcontainer.json +configuration is required for it. What it does **not** do is copy any key +material in -- not the private key, and, for SSH-format signing, not even the +public key file. See VS Code's own docs on [sharing Git credentials][] for the +authoritative description. + +That gap matters because of how the two signing formats differ: + +- **`gpg.format=openpgp`** (classic GPG): the forwarded agent alone is enough. + `gpg` talks to the agent socket and never needs a local copy of anything. + `post-create.sh` runs `gpg --list-keys` once so the container's keyring files + exist; beyond that, there is nothing this repo needs to do. +- **`gpg.format=ssh`**: Git shells out to + `ssh-keygen -Y sign -f ...`. That `-f` argument is a **file + path**, and `user.signingkey` in a gitconfig copied from your host points at a + host path (typically `~/.ssh/id_ed25519.pub`) that has never existed in the + container. The forwarded agent doesn't help until that file exists -- and the + container's non-root user usually can't even create it: a Mac's `/Users/` + or a Linux host's `/home/` both live under a root-owned directory this + container's `node` user has no write access to, so recreating the host's path + byte-for-byte fails with a permissions error regardless of host OS. + +`.devcontainer/post-start.sh` closes that second gap. It runs on every container +**start/attach**, unlike `post-create.sh`, which only ever runs once, when the +container is first built -- too early, since the forwarded agent socket is a +fresh, per-session thing set up on each attach. If `gpg.format` is `ssh` and the +forwarded agent is holding exactly one identity, `post-start.sh` writes that +public key to a path under `$HOME/.ssh` in the container (not the host path +copied into `user.signingkey`) and repoints the container's own +`user.signingkey` at it. It deliberately does nothing if the agent has zero +identities (nothing to write) or more than one (no reliable way to know which +one you mean) -- watch its output on attach to see which case you're in. + +Either way, the actual cryptographic signing still happens on the host, via the +forwarded agent. No private key material is ever copied into the container. + +## Setting up SSH-format signing (recommended) + +Recommended because it's the less fiddly of the two to get working across host +and container, not because any tool requires it. + +Note that GitHub Desktop has no commit-signing setting of its own and no key of +its own. It shells out to Git and inherits whatever `git config` says, so the +steps below are the entire setup whether you commit from Desktop or from a +terminal. A "Verified" badge on GitHub is _not_ evidence that local signing is +configured: commits made or squash-merged through github.com are signed +server-side with GitHub's own web-flow key, which looks identical on the site +and involves nothing on your machine. + +- Make sure the key you want to sign with is loaded into your platform's SSH + agent: + + ```console + ssh-add -l + ``` + + If it isn't listed, add it. On macOS, add `--apple-use-keychain` so it + survives a reboot instead of needing `ssh-add` again every session: + + ```console + ssh-add --apple-use-keychain ~/.ssh/id_ed25519 + ``` + +- Point Git at it. Run this **on the host**, in a host terminal -- the container + gets its own copy of `~/.gitconfig` at build time, so running it inside the + container configures only the container and silently leaves the Mac unchanged: + + ```console + git config --global gpg.format ssh + git config --global user.signingkey ~/.ssh/id_ed25519.pub + git config --global commit.gpgsign true + ``` + +- Reopen or rebuild the devcontainer and watch `post-start.sh`'s output on + attach. `Commit signing ready` means the public key was found in the forwarded + agent and written into the container. Anything else means the agent forwarded + into _this_ session doesn't have exactly one identity -- check `ssh-add -l` on + the host first. + +Use an ordinary `ssh-keygen`-generated key pair here. Keys that exist only +inside a Secure Enclave or an external agent, with no public key file on disk, +are a poor fit: `user.signingkey` has to name a real path on the host, and +`post-start.sh` needs a public key it can write out in the container. The two +paths don't need to match -- `post-start.sh` retargets the container's own copy +of `user.signingkey` to wherever it actually writes the file, under +`$HOME/.ssh`. + +To confirm signing is actually working locally rather than assuming it, commit +and then check that the object really carries a signature: -## Connecting to GitHub with SSH - -You can connect to GitHub using the Secure Shell Protocol (SSH), which provides -a secure channel over an unsecured network. - -Using the SSH protocol, you can connect and authenticate to remote servers and -services. With SSH keys, you can connect to GitHub without supplying your -username and personal access token at each visit. - -When one sets up SSH, it's necessary to first generate a new SSH key and then -add it to the **[`ssh-agent`][]**. One must add the SSH key to their account on -GitHub before any usage of the key to authenticate may occur. - -### 1.1.1     Generating a new SSH key and adding it to the ssh-agent - -If you don't already have an SSH key, you must generate a new one for -authentication. You can check for existing keys if you are unsure whether you -already have an SSH key. For more information, see "[Checking for existing SSH -keys][]". - -If you don't want to reenter your passphrase every time you use your SSH key, -you can add your key to the SSH agent, which will manage your SSH keys and -remember your passphrases. - -#### 1.1.1.1    Working with SSH key passphrases - -You can secure your SSH keys and configure an authentication agent so that you -won't have to reenter your passphrase every time you use your SSH keys. - -With SSH keys, if someone gains access to your computer, they also gain access -to every system that uses that key. To add an extra layer of security, you can -add a passphrase to your SSH key. You can use `ssh``-agent` to save your -passphrase securely, so you don't have to reenter it. - -## 1.2    Adding or changing a passphrase - -### 1.2.1     Adding a new SSH key to your GitHub account - -You can further secure your SSH key by using a hardware security key, which -requires the physical hardware security key to be attached to your computer when -the key pair is used to authenticate with SSH. You can also secure your SSH key -by adding your key to the ssh-agent and using a passphrase. For more -information, see "[Working with SSH key passphrases][]". - -## 1.3    Auto-start of the gpg-agent - -The _gpg-agent_ is the central part of the GnuPG system. It takes care of all -private (secret) keys and, if required, diverts operations to a smartcard or -other token. It also supports Secure Shell (SSH) by implementing the ssh-agent -protocol. - -The traditional way to run _gpg-agent_ on \*nix systems is by launching it at -login time and using an environment variable (GPG_AGENT_INFO) to tell the other -GnuPG modules how to connect to the agent. However, correctly managing the -startup and this environment variable is cumbersome, so a more straightforward -method is required. Since GnuPG 2.0.16, the --use-standard-socket option already -allowed starting the agent on the fly; however, the environment variable was -still needed. - -With GnuPG 2.1, the need for GPG_AGENT_INFO has been completely removed, and the -variable is ignored. - -Instead, a fixed _Unix domain socket_ named S.gpg-agent in the GnuPG home -directory (by default ~/.gnupg) is used. The agent is also started on-demand by -all tools requiring services from the agent. - -If the option `--enable-ssh-support` is used, the auto-start mechanism does not -work because _ssh_ does not know about this mechanism. Instead, the environment -variable `SSH_AUTH_SOCK` must be set to the `S.gpg-agent.ssh` socket in the -GnuPG home directory. Further, `gpg-agent` must be started by either using a -GnuPG command that implicitly starts `gpg-agent` or by using -`gpgconf --launch gpg-agent` to explicitly start it without first having to use -a GnuPG command. - -`gpg-agent` is a daemon to manage secret (private) keys independently from any -protocol. It is a backend for gpg, gpgsm, and other utilities. - -GPG Agent Configuration - -There are a few configuration files needed for the operation of the agent. They -may all be found in the current GnuPG home directory, which defaults -to ~/.gnupg. - -:::windows - -However, there may be problems on Windows systems with Gpg4Win installed; -**Gpg4Win may have changed this default GnuPG home directory location** to an -AppData subdirectory (i.e., `C:\Users\\AppData\Roaming\gnupg`). This -location, however, is not the location our GPG agent will be using, so to -reaffirm our preference for the default location, we will set -the GNUPGHOME environment variable to ~/.gnupg in the Git Bash startup script by -running the following. - -echo 'export GNUPGHOME="~/.gnupg"' >> .bashrc - -::: - -Setting environment variables - -Add the following lines to your .bashrc or whatever initialization file is used -for all shell invocations: - -GPG_TTY=$(tty) - -export GPG_TTY - -This variable may only be helpful if you use `pinentry-curses` (the -terminal-based pin entry program). - -:::windows - -On Windows systems, you should add the above lines to the ~/.bashrc file for use -by Git Bash. - -::: - -GnuPG configuration - -It's important to note that GnuPG on the remote system still needs your public -GPG keys to work correctly. So you have to ensure they are available on the -remote system even if your secret keys are not. - -:::note{.note} - -If you use VSCode with the remote extension pack, you may skip this step and -move on to the next section. This step of copying over your local public GPG -keyring into the remote container gets done automatically by the extension. - -::: - -:::excerpt{.quote} - -[SCP]{#scp .dfn} is a means of -securely transferring [computer files][] between a local [host][] and a remote -host or between two remote hosts. It is based on the [Secure Shell][] (SSH) -protocol.[^1] "SCP" commonly refers to both the Secure Copy Protocol and the -program itself.[^2] - - - -::: - -During _**[`ssh-agent`][]** initialization_, the extra socket (named -**`S.gpg-agent.extra`** by default) gets created in the GnuPG home directory. - -The intended use for this extra socket is to set up a _Unix domain socket_ -forwarding from a remote machine to this socket on the local device. -A gpg process running on the remote box (or, in our case, in the devcontainer) -may connect to the local gpg-agent and use its private keys. This activity -enables decrypting or signing data on a remote machine without exposing the -private keys to the remote box. Although this technique is usually taken as a -precaution when the connection between two systems goes over a hostile network, -it is convenient to avoid transferring private keys to the devcontainer. - -### 1.3.1.1    Manually specify GPG agent configuration - -To guarantee that the connection (going over a kernel IPC channel) between the -two systems goes to the right place, it is advisable to explicitly specify the -local filename (in full) of the extra socket in the GPG agent config file. Do so -by adding the following line to the `gpg-agent.conf` file in the GnuPG home -directory. - -```text -extra-socket /c/Users//.gnupg/S.gpg-agent.extra +```console +git cat-file commit HEAD | head -20 ``` -This extra socket is the one our local `gpg-agent` will be using rather than -S.gpg-agent because its limitations theoretically make it more secure. +A locally signed commit has a `gpgsig` header (`BEGIN SSH SIGNATURE` for this +format). No header means the commit is unsigned no matter what the settings say. -Enable GPG agent support of SSH +Prefer that check over `git log --show-signature` when the question is whether +_signing_ works: `cat-file` reads the commit, while `--show-signature` also has +to verify it, which is a separate mechanism that can fail on its own. See +[below](#when-show-signature-says-no-signature) for what that looks like. -Add the following line to your GPG-agent config file. - -```text -enable-ssh-support -``` +## Verifying signatures locally -The OpenSSH Agent protocol is always enabled, but `gpg-agent` will only set -the `SSH_AUTH_SOCK` environment variable with this option specified. +Verification is a distinct mechanism from signing, with its own configuration +and its own failure modes -- a commit can be perfectly signed and still fail to +verify here. For SSH-format signatures, Git needs an [allowed signers][] file +mapping each principal (an email address) to the keys it may sign with. Unlike +GPG, where the keyring is discovered automatically, Git has no default location +for this file, so verification cannot run at all until +`gpg.ssh.allowedSignersFile` names one. -In this mode of operation, the agent implements both the `gpg-agent` protocol -and the agent protocol used by OpenSSH (through a separate socket). -Consequently, using the `gpg-agent` as a drop-in replacement for the -well-known `ssh-agent` should be possible. +`post-start.sh` writes `$HOME/.ssh/allowed_signers` alongside the signing key it +already sets up, listing your `user.email` against that key, and points the +config at it. That is enough for `git log --show-signature` to report +`Good "git" signature`. -SSH keys, intended for use through the agent, need to be added to the -gpg-agent initially through the ssh-add utility. Upon adding a key, ssh-add will -ask for the password of the provided key file and send the unprotected key -material to the agent. This routine will cause the gpg-agent to ask for a -passphrase, which it will use to encrypt the newly-received key and store it in -a gpg-agent-specific directory for later use. Once an SSH key has been added to -the gpg-agent in this manner, the gpg-agent will be ready to use the newly-added -key. +Two things it deliberately does not attempt: -:::note{.note} - -If the `gpg-agent` receives a signature request, the user may need prompting for -a passphrase, which is necessary to decrypt any SSH keys stored. Since -the ssh-agent protocol does not contain a mechanism for telling the agent on -which display/terminal it's running, gpg-agent's ssh-support will use the TTY or -X display where gpg-agent started. To switch this display to the current one, -you may use the following command. - -```console -gpg-connect-agent updatestartuptty /bye -``` +- **Anyone else's commits.** The file lists your key and no one else's, so other + contributors' signed commits report `No principal matched`. Verifying those + means maintaining a shared allowed-signers file, which is a project-wide + decision rather than something a container script should invent. +- **Trust beyond your own attestation.** You are asserting that this key belongs + to this address. That makes local verification meaningful for catching a + misconfigured or swapped key; it is not third-party attestation the way + GitHub's "Verified" badge is. GitHub does its own check against the keys + registered on your account -- see its docs on [commit signature + verification][], and note that a key has to be added as a **signing** key + there, separately from the same key added for authentication. -::: +### When show-signature says No signature -Although all GnuPG components try to start the **[`gpg-agent`][]** as needed, -this is not possible for _the **[`ssh`][]** support_ because **[`ssh`][]** does -not know about it. Thus, if no GnuPG tool, that usually accesses the -**[`gpg-agent`][]** (causing the initial start of it) ever ran, there is no -guarantee that **[`ssh`][]** can use **[`gpg-agent`][]** for authentication. To -fix this, one may start **[`gpg-agent`][]** , if needed, by using this simple -command: +If the allowed-signers file is missing or unconfigured, +`git log --show-signature` prints (wrapped here for width): ```console -gpg-connect-agent /bye +error: gpg.ssh.allowedSignersFile needs to be configured and exist + for ssh signature verification +No signature ``` -:::note{.tip} - -Adding the `--verbose` flag shows the progress of starting the agent. - -::: - -### Correctly managing the startup of the GPG agent - -The traditional way to run _gpg-agent_ on \*nix systems is by launching it at -login time. - -To be sure, we will add the following line to… - -:::windows - -The `--enable-putty-support` flag is only available under Windows and allows the -use of gpg-agent with the PuTTY implementation of SSH. This usage is similar to -the regular ssh-agent, which supports OpenSSH implementations of SSH on \*nix -systems, but differs in its use of Windows Message Queues as PuTTY requires. - -::: - -to load configuration details - -#### 1.3.1.2    specify SSH configuration - -SSH configuration - -Add the following to the file located at ~/.ssh/config. If it does not yet -exist, create it. - -```text -host gpgtunnel - -hostname localhost - -port 2222 - -User vscode - -RemoteForward /home/vscode/.gnupg/S.gpg-agent -/c/Users//.gnupg/S.gpg-agent.extra -``` +`No signature` here is the verifier reporting that it could not run -- not a +statement about the commit, which may well be signed. The wording invites the +opposite reading, and acting on it means re-checking `commit.gpgsign`, +`user.signingkey` and the agent, all of which were fine. Confirm with +`git cat-file commit HEAD` before changing any signing setting: a +`BEGIN SSH SIGNATURE` header means signing works and only verification needs +attention. Note that the `error:` line is easy to miss when it scrolls past +above the commit, or when a pager or tool shows only the commit body. + +## Setting up GPG-format signing + +If you use an actual OpenPGP key instead: + +- Make sure `gpg-agent` on the host has your key and is reachable the normal way + (`gpg --list-secret-keys` should show it). +- Leave `gpg.format` unset (or set it to `openpgp`), and set: + + ```console + git config --global user.signingkey + git config --global commit.gpgsign true + ``` + +- Nothing in this repo's devcontainer needs configuring beyond what's already + there: `gnupg` ships in the base image, and the forwarded agent socket is all + `gpg` needs. + +## Troubleshooting + +- **`ssh-add -l` says "The agent has no identities"** -- this is a host-side + fact, not a container problem. Add the key on the host and reattach. +- **`post-start.sh` reports more than one identity** -- it won't guess. Either + unload the extra identities from the agent for this session, or, inside the + container, write the file yourself from the one you mean, then point + `user.signingkey` at it: + + ```console + ssh-add -L | grep > ~/.ssh/id_ed25519.pub + git config --global user.signingkey ~/.ssh/id_ed25519.pub + ``` + +- **It worked before, stopped working after a container rebuild** -- the signing + key and `allowed_signers` files `post-start.sh` writes, and the + `user.signingkey`/`gpg.ssh.allowedSignersFile` overrides pointing at them, all + live in the container's filesystem, not a volume, so a rebuild removes them + along with the host's copied-in gitconfig. Everything gets rewritten on the + next attach as long as the agent still has exactly one identity at that point. +- **`post-start.sh` says "Signature verification NOT configured: no + user.email"** -- it needs `user.email` to know which principal to list against + your key in `allowed_signers`, and won't guess one. Set it (globally, on the + host, same as the other signing settings) and reattach: + + ```console + git config --global user.email you@example.com + ``` + +- **`git log --show-signature` says `No signature`** -- establish that the + commit is actually unsigned before treating it as a signing problem, since + that message is also what a verifier that could not run prints. + `git cat-file commit HEAD` settles it; see + [above](#when-show-signature-says-no-signature). +- **Everything looks configured, but commits still come out unsigned** -- check + for a per-repository override before re-checking anything global: + + ```console + git config --local --get commit.gpgsign + ``` + + `false` here beats `commit.gpgsign = true` in your global config, silently and + for every tool touching the clone. It is worth ruling out early: `.git/config` + isn't version controlled, so nothing in a PR can fix it and nothing in a diff + reveals it, and because the working tree is bind-mounted from the host, a + `--local` setting applied inside the container is applied to the host clone + too. Clear it with `git config --local --unset commit.gpgsign`. -[^1]: https://en.wikipedia.org/wiki/Secure_copy_protocol#cite_note-1 -[^2]: https://en.wikipedia.org/wiki/Secure_copy_protocol#cite_note-Pechanec-2 - -[`ssh`]: https://en.wikipedia.org/wiki/Secure_Shell -[`ssh-agent`]: https://en.wikipedia.org/wiki/Ssh-agent -[`gpg-agent`]: https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html -[Checking for existing SSH keys]: https://docs.github.com/en/github/authenticating-to-github/checking-for-existing-ssh-keys -[computer files]: https://en.wikipedia.org/wiki/Computer_file -[host]: https://en.wikipedia.org/wiki/Server_(computing) -[Secure Shell]: https://en.wikipedia.org/wiki/Secure_Shell -[Working with SSH key passphrases]: https://docs.github.com/en/github/authenticating-to-github/working-with-ssh-key-passphrases +[#1775]: https://github.com/OpenINF/openinf.github.io/pull/1775 +[allowed signers]: https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS +[sharing Git credentials]: https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials +[commit signature verification]: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification diff --git a/project-terms.txt b/project-terms.txt index 3eff81031..f54c3c0bf 100755 --- a/project-terms.txt +++ b/project-terms.txt @@ -31,6 +31,8 @@ gpg gpg4win Gpg4win gpgconf +gpgsig +gpgsign gpgsm gpgtunnel Grault @@ -51,23 +53,26 @@ OpenINF openinfbot OpenINFbot OpenINFBot +openpgp outro pinentry Potenti PowerShell -psusan Quux Renovatebot +repoints +retargets rubocop screencap scssify sdcard SDK Servagility +signingkey siteify skipcq SLOCs smartcard soonish UI -updatestartuptty +unconfigured