DownloadSecureFileV1 task silently fails to download .pfx file (creates an invalid cert file which contains an error)

[adrastogi]

New issue checklist

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

Task name

DownloadSecureFile@1

Breaking task version

1.247.1

Last working task version

1.247.1

Regression Description

We have a .pfx file uploaded to the Pipelines -> Library -> Secure Files section of our Azure Devops project. We have been using the DownloadSecureFile@1 pipeline task to successfully pull down this certificate onto the build agent, where it is later used for signing some Windows MSIX packages (using signtool.exe).

The signtool.exe step started failing across our pipelines last week, and after some debugging, we realized it was because the .pfx file was no longer valid. Instead of a well-formed .pfx file, the task to download it from the project's secure files was reporting success but actually writing a truncated JSON error message!

{"$id":"1","innerException":null,"message":"TF15004: The download request signature has expired.","typeName":"Microsoft.TeamFoundation.Framework.Server.DownloadTicketValidationException, Microsoft.Tea

I couldn't find much about this error code from searching around. I did see a similar-looking Closed issue, which I commented on, but thought I'd also report this as a separate problem since it was repro'ing 100% of the time across our pipelines (we ended up having to switch to pulling the certificate from Azure Key Vault).

#15921 (comment)

The task version does not appear to have changed, but I am filing this as a regression because "something" adjacent to it appears to have broken.

At the very least, the task should not silently succeed even though there is an error!

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 Server 2022

Relevant log output

There was no error reported by the task (it silently passes, even though it records an error string in the file.)

##[debug]Downloaded secure file contents to: C:\__w\_temp\SelfSignedCertificate.pfx
##[debug]set secureFilePath=C:\__w\_temp\SelfSignedCertificate.pfx
##[debug]Processed: ##vso[task.setvariable variable=secureFilePath;isOutput=false;issecret=false;]C:\__w\_temp\SelfSignedCertificate.pfx
##[debug]Handler exit code: 0
Finishing: Download test signing certificate (windows_build_container)

Full task logs with system.debug enabled

The debug logs are from an internal engineering systems run, and I am not sure if there is sensitive information in the output. Please feel free to contact me for this data.

Repro steps

The pipelines are not open source, but the YAML task snippet looks like this. 

- task: DownloadSecureFile@1
  displayName: 'Download test signing certificate'
  name: TestCert
    inputs:
    secureFile: 'SelfSignedCertificate'

[MantavyaDh]

The task shouldn't have passed silently, this is a bug, however no changes have been made either the task DownloadSecureFileV1 or the common-package securefiles-common therefore not a regression.

[adrastogi]

@MantavyaDh thanks for looking- agree, the task looks unchanged (when I was comparing the passing / failing runs, the version was the same).

Whatever the task is invoking to achieve the download seems to have regressed (and exposed the other issue with the silent error)- so the net-effect is a regression IMO from a customer / end-user standpoint. Happy to help investigate this- feel free to follow up with me if you'd like more info.

[MantavyaDh]

Hi @adrastogi, I've checked that the API used to download the secure file in the common-package securefiles-common doesn't have any changes. Are you facing this error: TF15004: The download request signature has expired. intermittently or continously ?

[adrastogi]

@MantavyaDh thanks for investigating- this was 100% repro for us. We ended up having to switch over to downloading the cert from an Azure Key Vault since this was blocking all our pipelines.