JCASC creating corrupted file credential from DSA private key

Your checklist for this issue

🚨 Please review the guidelines for contributing to this repository.

• Jenkins version 2.269
• Plugin version

Plugin	Version
JCasC	1.46
Credentials	2.3.14
Plain Credentials	1.7

• OS Ubuntu

Description

I’m using JCasC to inject DSA credentials as a secret file and I’m getting unusual behavior that seemingly results in a corrupted credential file.

I’m setting up the file credential by doing the following:

credentials:
  system:
    domainCredentials:
    - credentials:
      - file:
          description: "DSA private key"
          fileName: "dsa_priv.pem"
          id: "dsa_priv"
          scope: GLOBAL
          secretBytes: "${base64:${file}}"

And by placing my credential at /run/secrets/file in order to load it via the docker secrets mechanism and then applying my configuration.

But JCasC doesn’t appear to be generating the same credential that would be created if I went through the Jenkins GUI and manually added a secret file to the credential store.

I noticed this because the script I’m running that attempts to read the JCasC created credential bombs because it can’t correctly deserialize it. But it works just fine on a file credential created from the GUI with the same contents.

But it’s also pretty easy to observe the difference in behavior with a simple pipeline script on a test key:

pipeline {
    agent any

    stages {
        stage('test') {
            environment {
                 dsa_priv= credentials('dsa_priv')
             }
            steps {
                script {
                    def contents = readFile file: env.dsa_priv
                    echo contents
                }
            }
        }
    }
}

When I attempt to read the credential loaded via the Jenkins GUI using the above pipeline, I get something that looks like:

-----BEGIN DSA PRIVATE KEY-----
...
-----END DSA PRIVATE KEY-----

But when I do same on the JCasC generated file credential, I get a bunch of mojibake:

���b
...
���b

Playing around some, if I swap the file contents for something like:

asdfsdf---
hello world
--asdfasdf

JCasC correctly creates the credential and dumps the contents:

[Pipeline] echo
asdfsdf---
hello world
--asdfasdf

But the moment I add a leading - to the file:

-asdfsdf---
hello world
--asdfasdf

Something goes wrong and I get nothing:

[Pipeline] echo

I’m not quite sure if the problem is with my usage, JCasC, or one of its dependent plugins (credentials, plain-credentials, etc.).

Thanks for all the work maintaining this great plugin and for taking the time to read my bug report!

[jetersen]

not sure how your passing in the file attribute but it my be the source of messing with the input.

Could you try using ${readFileBase64:myFilePath}

[sharksforarms]

My understanding from the doc is that:

1. `${base64:${readFile:/run/secrets/file}}`

2. `${readFileBase64:/run/secrets/file}`

3. `${base64:${file}}` _via docker secrets and content located at `/run/secrets/file`_

Should all be equivalent.

Update: And I would clearly be mistaken.

Given:

credentials:
  system:
    domainCredentials:
    - credentials:
      - file:
          description: "DSA private key"
          fileName: "dsa_priv.pem"
          id: "dsa_priv_A"
          scope: GLOBAL
          secretBytes: "${base64:${readFile:/run/secrets/file}}"
      - file:
          description: "DSA private key via readFileBase64"
          fileName: "dsa_priv.pem"
          id: "dsa_priv_B"
          scope: GLOBAL
          secretBytes: "${readFileBase64:/run/secrets/file}"
      - file:
          description: "DSA private key via docker secrets"
          fileName: "dsa_priv.pem"
          id: "dsa_priv_C"
          scope: GLOBAL
          secretBytes: "${base64:${file}}"

1 and 3 are the same and produced a corrupted dsa file. 2 produces the correct file.

Just hit this bug today. Switching to using readFileBase64 fixed my issue. I feel like all 3 should work though, this was a very confusing thing to search for.