Package io.jenkins.plugins.ephemeral_credentials

Class EphemeralCredentialSpec

java.lang.Object
io.jenkins.plugins.ephemeral_credentials.EphemeralCredentialSpec
All Implemented Interfaces:
Serializable
Direct Known Subclasses:
EphemeralCertificate, EphemeralSecretFile, EphemeralSecretText, EphemeralSSHUserPrivateKey, EphemeralUsernamePassword
public abstract class EphemeralCredentialSpec extends Object implements Serializable

Describes one credential a withEphemeralCredentials block may need to resolve interactively: which input parameters to ask the user for, and how to turn the collected answers into a concrete Credentials object. Concrete subtypes are constructed from pipeline script via the matching factory global variable, e.g. ephemeralUsernamePassword(id: 'FOO', description: '...') - the same ergonomics as usernamePassword(...) inside withCredentials.

Plain data/logic, never itself invokes a pipeline step, so unlike WithEphemeralCredentials it needs no special CPS treatment and is Serializable.

Heap exposure - what this plugin does and doesn't protect against

materialize(java.util.Map<java.lang.String, java.lang.Object>) necessarily handles secret plaintext (or decoded secret bytes) as an ordinary Java String/byte[] for the short time it takes to build the Credentials object - Strings are immutable and can't be scrubbed, so subclasses that decode their own byte[] copy (e.g. base64 content) should overwrite it (e.g. Arrays.fill(bytes, (byte) 0)) the moment it's no longer needed, rather than waiting on GC. This narrows one specific window, but doesn't change the bigger picture: once materialized, the Credentials object itself sits live in EphemeralCredentialsProvider's in-memory cache for the rest of the build, and its own plaintext is necessarily recoverable on demand (e.g. via Secret.getPlainText()) for as long as it's cached - that's what lets withCredentials bind it. A JVM heap dump taken during that window would expose it, the same as it would for any credential actively bound via withCredentials today; this plugin doesn't make that fundamentally worse, it just holds the secret live for the whole build instead of one withCredentials block, and nothing in the JVM/Java security model lets an ordinary plugin defend live, in-use plaintext against a memory dump of the process that legitimately holds it.

See Also:

  • Constructor Details

    • EphemeralCredentialSpec

      protected EphemeralCredentialSpec(String id, String description)

  • Method Details

    • getId

      public String getId()

    • getDescription

      public String getDescription()

    • inputParameters

      public abstract List<ParameterDefinition> inputParameters()
      Parameters to pass to the input step when this credential is missing. input's own message is the spec's getDescription() (falling back to a generic default), set by the caller - these are just the value-collecting fields.

    • materialize

      public abstract com.cloudbees.plugins.credentials.Credentials materialize(Map<String,Object> answers)
      Builds the credential from the input step's answers, keyed by the parameter names returned from inputParameters().