.github/workflows/java-publish.yml:61 passes the GPG passphrase via the command line, which makes it visible in process listings on the runner and risks being echoed into debug logs.
Proposed
Switch to a passphrase mechanism that doesn't expose the secret as a CLI arg:
gpg --pinentry-mode loopback --passphrase-fd 0 with the passphrase piped on stdin, OR- Maven's
gpg.passphrase property via environment variable, OR
gpg-agent preload before running Maven
Also worth checking: ensure -X/--debug is not enabled on Maven in the publish job (would echo secrets).
Related
Longer-term, consider replacing GPG-based signing with Sigstore via sigstore-maven-plugin — removes the need to manage a long-lived GPG key and passphrase at all. That's a bigger change; tracking separately if we pursue it.
Part of security review follow-up.
.github/workflows/java-publish.yml:61passes the GPG passphrase via the command line, which makes it visible in process listings on the runner and risks being echoed into debug logs.Proposed
Switch to a passphrase mechanism that doesn't expose the secret as a CLI arg:
gpg --pinentry-mode loopback --passphrase-fd 0with the passphrase piped on stdin, ORgpg.passphraseproperty via environment variable, ORgpg-agentpreload before running MavenAlso worth checking: ensure
-X/--debugis not enabled on Maven in the publish job (would echo secrets).Related
Longer-term, consider replacing GPG-based signing with Sigstore via
sigstore-maven-plugin— removes the need to manage a long-lived GPG key and passphrase at all. That's a bigger change; tracking separately if we pursue it.Part of security review follow-up.