[REGRESSION]: Secrets cannot contain multiple lines npmAuthenticate

[GSFZamai]

New issue checklist

• [X] I searched for existing GitHub issues
• [X] I read pipeline troubleshooting guide
• [X] I checked how to collect logs

Task name

npmAuthenticate

Breaking task version

0.241.1

Last working task version

0.238.3

Regression Description

A regression happened!

Yesterday I tryied to run my pipeline and this task failed:

After some research I've found this issue on StackOverflow reporting the same problem and one user suggested that this new version was released. So I tryied to downgrande the version and the task worked:

StackOverflow Reference

Environment type (Please select at least one enviroment where you face this issue)

• [ ] Self-Hosted
• [X] Microsoft Hosted
• [ ] VMSS Pool
• [ ] Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

macOS-latest

Relevant log output

Starting: npmAuthenticate
==============================================================================
Task         : npm authenticate (for task runners)
Description  : Don't use this task if you're also using the npm task. Provides npm credentials to an .npmrc file in your repository for the scope of the build. This enables npm task runners like gulp and Grunt to authenticate with private registries.
Version      : 0.241.1
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/package/npm-authenticate
==============================================================================
Adding authentication to the .npmrc file at /Users/runner/work/1/s/.npmrc
Adding credentials for the pkgs.dev.azure.com service connection
##[error]Error: Secrets cannot contain multiple lines
Finishing: npmAuthenticate

Full task logs with system.debug enabled

UNSUCCESSFUL RUN

 [REPLACE THIS WITH YOUR INFORMATION] 

SUCCESSFUL RUN

 [REPLACE THIS WITH YOUR INFORMATION] 

Repro steps

No response

[matt-vanderkolk]

I have a repro of this issue internally as well. Feel free to reach out.

[Lorondos]

We had this issue as well on our pipelines, we have implemented the hard coded previous version to fix our pipelines for now, but I figure the next step is to make our secrets valid by removing anything that flags as multiline?

[GSFZamai]

I don't know. I'm using the Npm Service connection with Personal Access Tokan (PAT) wich is a single line already... Looks like is some internal change on the commit they added a validation to match new lines caracters.

Added setSecret:

setSecret Implementation:

Maybe, in my case, the Npm Service connection is generating something with new lines characters...

[KnightCrawler3]

Facing the same issue with 0.241.1

[Nathanvdk]

We have the same problem since yesterday in our build pipelines.

[MelvinVermeer]

Facing the same issue

[alexander-miszko]

Facing the same issue with 0.241.0, downgrading the version fixes it.

[Srokap]

I did some digging and it seems that registry.auth will always be a multiline string because it is made into such format here.

See how auth value is built (lineEnd is os.EOL):

        switch (endpointAuth.scheme) {
            case 'UsernamePassword':
                username = endpointAuth.parameters['username'];
                password = endpointAuth.parameters['password'];
                email = username; // npm needs an email to be set in order to publish, this is ignored on npmjs
                password64 = Buffer.from(password).toString('base64');

                auth = nerfed + ':username=' + username + lineEnd;
                auth += nerfed + ':_password=' + password64 + lineEnd;
                auth += nerfed + ':email=' + email + lineEnd;
                break;
            case 'Token':
                const apitoken = endpointAuth.parameters['apitoken'];
                tl.setSecret(apitoken);
                if (!isVstsTokenAuth){
                    // Use Bearer auth as it was intended.
                    auth = nerfed + ':_authToken=' + apitoken + lineEnd;
                } else {
                    // Azure DevOps does not support PATs+Bearer only JWTs+Bearer
                    email = 'VssEmail';
                    username = 'VssToken';
                    password64 = Buffer.from(apitoken).toString('base64');

                    auth = nerfed + ':username=' + username + lineEnd;
                    auth += nerfed + ':_password=' + password64 + lineEnd;
                    auth += nerfed + ':email=' + email + lineEnd;
                }
                break;
        }
        tl.setSecret(password);
        tl.setSecret(password64);

As mentioned above, the bug was introduced in this PR https://github.com/microsoft/azure-pipelines-tasks/pull/19995/files

[Srokap]

FYI @tintse-thxsky-MSFT @embetten

[tintse-thxsky-MSFT]

ack, looking into it. Thank you for everyone's input.

[killerrin]

This issue has suddenly resurrected on our pipelines as well. Although in my case I'm already using the npmAuthenticate@0 task, so unfortunately I can't downgrade as a workaround :/

[Srokap]

@killerrin Temporary workaround would be to use

- task: npmAuthenticate@0.238.2

in your pipeline, though in my case I have a lot of pipelines to update :)

[killerrin]

@Srokap That did it, Thanks!

[janharders]

@killerrin Temporary workaround would be to use

- task: npmAuthenticate@0.238.2

in your pipeline, though in my case I have a lot of pipelines to update :)

@Srokap: Do you know if there is any option to specifiy the exact task version in a classic release pipeline (no YAML)? Thx in advance!

[Srokap]

@janharders Unfortunately I don't know of a way.

Your best bet might be trying to set SYSTEM_UNSAFEALLOWMULTILINESECRET environment variable to TRUE to bypass the multiline error, but it might cause unexpected behavior. I think it might "only" risk leaking your creds to stdout.

Have a look here, how it's implemented: https://github.com/microsoft/azure-pipelines-task-lib/blob/7c0de0dba61afb899068c35d88257017bd3b4736/node/task.ts#L241

[tintse-thxsky-MSFT]

update: rollback to previous task version should is ongoing.

[mpm-os]

Hi! Is the revert complete?

[janharders]

Hi! Is the revert complete?

Guess yes. Our pipelines are up and running again :-)