putting this in a server section is more in line with the recommended setup at http://maven.apache.org/plugins/maven-gpg-plugin/usage.html#Configure_passphrase_in_settings.xml and also later on would allow for storing it in an encrypted fashion. Having it in a default profile as property is just too much overhead IMHO.

Should we default to an empty string here?

This does default to an empty string. Just like GITHUB_TOKEN and GITHUB_ACTOR are environment variables, GPG_PASSPHRASE is an environment variable as well.

If a user doesn't specify a GPG key, won't this be empty?

Will that cause issues for users who don't want GPG authentication

Users will see the following by default whether they want GPG authentication or not:

<settings>
    <servers>
      <server>
        <id>github</id>
        <username>${env.GITHUB_ACTOR}</username>
        <password>${env.GITHUB_TOKEN}</password>
      </server>
      <server>
        <id>gpg.passphrase</id>
        <passphrase>${env.GPG_PASSPHRASE}</passphrase>
      </server>
    </servers>
</settings>

And GPG_PASSPHRASE won't be provided so it will be empty string. This isn't a problem for users that don't want GPG -- maven will behave normally and will only grab information from this other server config if it needs it for the GPG plugin.

I know this is the common default but in a shared runner I think we wanted to allow for paths outside the home directory such that I could drop this into a temp dir.

Yeah, I was worried about that. While the private key is being stored in a "temporary" directory inside the home directory, two setup-java actions running on a shared runner could potentially conflict.

Are you suggesting that we allow users to specify a a temporary private key directory, similar to what is already done with the settings-path option? Or would you rather see setup-java create a temporary directory using os.tmpdir() based on the repository + unique run ID without any prompting. It looks like using $GITHUB_WORKSPACE/.tmp or something is an alternative as well.

I was thinking more along the lines of the latter -- creating a known good temporary directory for the user without asking -- since a user shouldn't care about where the private key file is being written because it's being deleted.

Side note -- this comment about shared runners also brings up the potential need for a temporary key ring. After import, the GPG keyring sticks around and can be used by other runs. This wouldn't be a problem with the hosted runner because it's a new environment every time. A better approach for the shared, self-hosted runners might be to import using a temporary key ring and then clean it up in a post step.

Let me know your thoughts and I can take another crack at this 😄

For a temporary directory, you can use RUNNER_TEMP:

The path of the temporary directory for the runner. This directory is guaranteed to be empty at the start of each job, even on self-hosted runners.
https://help.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#runner-context

Code example: https://github.com/actions/toolkit/blob/83dd3ef0f1e5bc93c5ab7072e1edf1715a01ba9d/packages/tool-cache/src/tool-cache.ts#L555

Ah, thanks! I see now that installer.ts is already using this directory as well. Updated PR to use the temp directory but some more improvements can be made since installer.ts apparently already has some logic built in for fallbacks. I'll move that common temp directory logic to a separate file that both auth.ts and installer.ts use in a future commit.

The temporary key ring thing is unfortunately more complicated than I originally thought. You can't just create and use a temporary key ring without also telling the maven gpg plugin to use the same configuration.

If we want to isolate the gpg keyring for shared runners, the cleanest way I've found is to specify a new GPG home directory that lives in the temp directory. This means that each job will get its own brand new GPG configuration that is cleaned up before the next job run.

To start, we will have to import the private key via:

gpg --homedir $RUNNER_TEMP/.gnupg/ --import --batch private.asc

However, using --homedir only affects that particular import command. Future GPG commands will use the default GPG home directory which is a problem for us when it comes invoking GPG later with Maven. To fix this, we have to provide a home directory override for the GPG plugin too.

The resulting settings.xml file would then look like:

<servers>
    <server>
      <id>github</id>
      <username>${env.GITHUB_ACTOR}</username>
      <password>${env.GITHUB_TOKEN}</password>
    </server>
    <server>
      <id>gpg.passphrase</id>
      <passphrase>${env.GPG_PASSPHRASE}</passphrase>
    </server>
    <profiles>
        <profile>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <gpg.homedir>${env.RUNNER_TEMP}</gpg.homedir>
            </properties>
        </profile>
    </profiles>
</servers>

Creating this default GPG home directory override in the Maven settings will break existing setup-java users that have scripted their own GPG import solution. We need to generate a different settings.xml for users that haven't specified a private key:

<servers>
    <server>
      <id>github</id>
      <username>${env.GITHUB_ACTOR}</username>
      <password>${env.GITHUB_TOKEN}</password>
    </server>
</servers>

NOTE: The second gpg.passphrase server section can stay as-is without any harm but we might as well remove it if we're already conditionally generating settings.xml based on parameters.

This is going to be a bit more difficult to implement and it's already late here. I'll get cracking on this when I can.