Add Linux code signing in Docker

[freakboy3742]

What is the problem or limitation you are having?

PR #2973 added support for code signing Linux system packages - but only when running natively. If you use --target to build a package in a Docker container, code signing fails.

Describe the solution you'd like

It should be possible to build and sign a Linux package inside a Docker container.

There's no changes needed to the general workflow - identity selection etc can continue as currently defined. The signing identity and gnupg must exist on the "host" machine (which may be a macOS machine). However, as part of container preparation, the Docker container must have the required tools installed, and the chosen signing identity must be injected into the Docker container (presumably by exporting the key from the local machine, and adding it to the keychain inside the Docker container). The signing step must also occur inside the Docker container.

Describe alternatives you've considered

Status quo - only allow "native" signed package builds. This isn't ideal, as Docker builds are a major usability affordance.

Additional context

No response

[freakboy3742]

Tagging @siddhant-bayas for visibility, as the author of #2973.

[siddhant-bayas]

Hi @freakboy3742, I've finished implementing Docker-based signing for Linux system packages (the follow-up to #2973 / issue #2984). A few implementation details came up that I'd like to check with you before I put the PR up.

• Signing tools are always installed in the image. The Docker image gets built during verify_app_tools, which happens before the signing identity is chosen. Since identity selection is interactive, and existing images aren't rebuilt, there's no way to know at image build time whether signing will actually be used. Because of that, I add the signing tools (debsigs / rpm-sign / gnupg) to SYSTEM_REQUIRES for every image build. It means a few extra packages end up in every image, but it avoids needing a rebuild later if signing is enabled. Does that seem like a reasonable tradeoff?

• Key injection uses a mounted file and a single container run. The host exports the secret key to a file under self.data_path, which is already mounted at /briefcase. Then one container run does gpg --batch --import <key> && <sign command>, and the key file is cleaned up in a finally block. The key never ends up in an image layer or sticks around in the container. Is this what you had in mind when you mentioned exporting the key from the local environment and injecting it into the container, or would you prefer streaming it over stdin instead?

• /dist is only mounted for the signing step. The sign step passes mounts=[(self.dist_path, "/dist")] through the existing DockerAppContext.run() mount handling instead of making dist a permanent mount. That keeps the signed artifact out of the data_path volume and avoids changing the default container setup.

• SUSE doesn't have a separate rpm-sign package. On SUSE, rpmsign comes from rpm-build, which the image already installs, so there isn't a separate rpm-sign package to add. Right now I just return [] for SUSE instead of trying to install a package that doesn't exist.

P.S. English isn't my first language, so there might be a few weird phrasings or mistakes in here. Sorry about that.

[freakboy3742]

• Signing tools are always installed in the image.

Yes - that's what I would have expected. The extra signing tools aren't that large, so carrying around a very slightly larger image so that if signing is needed later isn't a concern.

• Key injection uses a mounted file and a single container run. The host exports the secret key to a file under self.data_path, which is already mounted at /briefcase. Then one container run does gpg --batch --import <key> && <sign command>, and the key file is cleaned up in a finally block. The key never ends up in an image layer or sticks around in the container. Is this what you had in mind when you mentioned exporting the key from the local environment and injecting it into the container, or would you prefer streaming it over stdin instead?

That approach could work. A better approach (thanks to @coderanger for this suggestion) would be to mount the host user's local ~/.gpg folder into whatever location gpg --import would store content inside the container. That way, the private key is never stored in the container, even in a transient image - but it is visible to the container for the purposes of signing. That mount is only needed when you run the actual code signing step.

• /dist is only mounted for the signing step.

That makes sense. There's no reason to mount a folder if it's not being used.

• SUSE doesn't have a separate rpm-sign package. On SUSE, rpmsign comes from rpm-build, which the image already installs, so there isn't a separate rpm-sign package to add. Right now I just return [] for SUSE instead of trying to install a package that doesn't exist.

That makes sense as well.

P.S. English isn't my first language, so there might be a few weird phrasings or mistakes in here. Sorry about that.

You're doing fine - and besides, your English is much better than my Hindi (I'm guessing?), so I'm not going to nit-pick some odd words :-)

[siddhant-bayas]

That approach could work. A better approach (thanks to @coderanger for this suggestion) would be to mount the host user's local ~/.gpg folder into whatever location gpg --import would store content inside the container. That way, the private key is never stored in the container, even in a transient image - but it is visible to the container for the purposes of signing. That mount is only needed when you run the actual code signing step.

Thanks, and thanks to @coderanger for the suggestion. I prototyped the "mount the host ~/.gnupg into the container" approach before changing anything, and it hits a portability problem: raw keyring directories aren't compatible between gpg versions.

My machine runs gpg 2.4.9, which stores public keys in the new SQLite keybox (public-keys.d/pubring.db). The Debian bookworm build container ships gpg 2.2.40, which only knows the older pubring.kbx. Mounting the host's ~/.gnupg into that container and setting GNUPGHOME:

• shows no keys at all (gpg --list-secret-keys comes back empty),
• makes the container gpg create a fresh empty pubring.kbx inside the host's ~/.gnupg, and
• because the home dir has to be writable (gpg needs to write lock files), the container spawns its own agent and writes S.gpg-agent* sockets into the host's ~/.gnupg, leaving stale root-owned files behind after the container exits.

So mounting the host keyring directly is version-fragile and mutates the host's keyring state. The export/import path avoids all of this: gpg --export-secret-keys is the version-independent transfer format, the host keyring is never touched, and the exported key file is already only visible to the container through the /briefcase bind mount (never in an image layer) and is deleted immediately after signing. I suggest we keep export/import for that reason. What do you think?

[freakboy3742]

So mounting the host keyring directly is version-fragile and mutates the host's keyring state. The export/import path avoids all of this: gpg --export-secret-keys is the version-independent transfer format, the host keyring is never touched, and the exported key file is already only visible to the container through the /briefcase bind mount (never in an image layer) and is deleted immediately after signing. I suggest we keep export/import for that reason. What do you think?

Thanks for that analysis - it makes sense that format compatibility between versions might be an issue.

As noted on my review of your PR, having a private key without password protection potentially cached into a Docker image makes me very nervous. I've seen some suggestion online that it might be possible to use the gpg daemon in agent mode to use the host machine to perform the actual signing. I'd like to explore that a bit first before committing to anything that might put files on disk.