[BUG]: AzureFileCopy@5 with AdditionalArgumentsForBlobCopy breaks by replacing asterisks

[htuomas]

Task name

AzureFileCopy

Task version

5.228.1

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

• Self-Hosted
• 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

windows-2022

Task log

With version 5.226.1:

Arguments are sanitized, input arguments result: '--cache-control no-cache --include-pattern "_#removed#_.html_#removed#__#removed#_.css_#removed#__#removed#_.js_#removed#__#removed#_.png"'

Relevant log output

With version 5.228.1:

##[error]Detected characters in arguments that may not be executed correctly by the shell.  Please escape special characters using backtick (`). More information is available here: <https://aka.ms/ado/75787>

Aditional info

This task has started failing some day after 12th of Sept. I tried reverting the version to a previously successful one (5.226.1), but that doesn't do the job even though it doesn't fail - it replaces the asterisks and semicolons in command parameters with "_#removed#_". I have also tried major version 4, but the outcome is the same. Inserting backticks before asterisks and semicolons didn't do anything, and the aka.ms url only lead to the Bing frontpage.
My task in yaml:

                - task: [email protected]
                  displayName: "Copy UI files to Storage account"
                  inputs:
                    SourcePath: "$(Pipeline.Workspace)/$(projectName).UI/*"
                    azureSubscription: "${{ parameters.azureSubscriptionName }}"
                    Destination: "AzureBlob"
                    storage: "$(customUiStorageAccountName)"
                    ContainerName: "$(customUiContainerName)"
                    AdditionalArgumentsForBlobCopy: '--cache-control no-cache --include-pattern "*.html;*.css;*.js;*.png"'

[ghost]

Hello @htuomas ;

Here is the page of documentation link in the error message:
Enable shell tasks arguments parameter validation

It looks like Enable shell tasks arguments parameter validation is enabled on your case; you can disable it as described in the page.

[merlynomsft]

Hello @htuomas -- the aka link https://aka.ms/ado/75787 should take you to https://learn.microsoft.com/en-us/azure/devops/pipelines/security/inputs?view=azure-devops#shellTasksValidation. Make sure you don't copy+paste the trailing >. Please let us know if that is not the case for you.

[htuomas]

I see that Azure DevOps log viewer interprets the closing > as part of the url, my bad I didn't check for that.

I tried escaping all quotes, semicolons (and asterisks to be sure) with the backtick as instructed in the documentation, but it's still not working with the 5.228.1. I will need to ask an admin to disable that shell validation setting in our environment, as I can't do it myself. But why does it work differently with 5.226.1 and 5.228.1? The other covertly replacing chars and the other just plainly failing, not giving the exact line and char it stumbles upon.

[merlynomsft]

Hi @htuomas -- thank you for the detailed feedback, really appreciate it. To answer your question, there were previous iterations of the validation functionality that behaved differently prior to shell validation being added as an option in the server settings.

Adding @KonstantinTyukalov. My thought is we should remove the <> from the error messages due to the issue of the log viewer including the closing > -- as mentioned, it's confusing now since with the closing >, clicking the link will go to a the bing.com page as mentioned.

[fforjan]

@merlynomsft sorry if it doesn't belong here but not sure where to create the issue, where can I find clearly the rule for the sanitizer in https://learn.microsoft.com/en-us/azure/devops/pipelines/security/inputs?view=azure-devops#enable-shell-tasks-arguments-parameter-validation

in our case, we are using the powershell task with argument list to invoke a script, argument list being "my/path $false" - i.e. the powershell script take a path and a boolean.
With the sanitizer on, the $false is rejected but we have no idea how to fix that. It seems we also tried "my/path 0" and it got rejected.

updated: some other teams member have seen issue when the arugment list is something like "$env:EnvVariable $false"

[merlynomsft]

@fforjan -- Thank you for the feedback, appreciate it! We will look into it. tagging: @KonstantinTyukalov

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days