stefankert / azuredevops-codesigning-task

Hi there 👋

azuredevops-codesigning-task's Issues

The specified PFX password is not correct?

Password is confirmed to be correct, hashing mechanism should be SHA256, we can import the certificate locally without issue, but we get this error:

2019-02-25T13:50:15.9108131Z SignTool Error: The specified PFX password is not correct.
2019-02-25T13:50:15.9108601Z
2019-02-25T13:50:15.9108813Z at ChildProcess.exithandler (child_process.js:204:12)
2019-02-25T13:50:15.9108976Z at emitTwo (events.js:106:13)
2019-02-25T13:50:15.9109154Z at ChildProcess.emit (events.js:191:7)
2019-02-25T13:50:15.9109310Z at maybeClose (internal/child_process.js:886:16)
2019-02-25T13:50:15.9109497Z at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
2019-02-25T13:50:15.9109670Z killed: false,
2019-02-25T13:50:15.9110367Z code: 1,
2019-02-25T13:50:15.9110679Z signal: null,
2019-02-25T13:50:15.9168732Z ##[error]Command failed: D:\a_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\signtool.exe sign /fd SHA256 /t http://timestamp.digicert.com /f D:\a_temp\ErpMaestroCSCert.pfx /p [Our Password] D:\a\r1\a_artifact\Application\coreapp\win7-x64\ErpMaestro.Agents.Application.exe
SignTool Error: The specified PFX password is not correct.

PFX without a password?

Is it possible to use a PFX file without a password? On my local machine I typically sign with:

signtool.exe sign /f mycert.pfx myApp.exe

Sign multiple search patterns

Love this task, thanks for your time!

Just one question. Is it possible to make the "File(s) to sign" field multiline? So we can have a config like this:

  - task: codesigning@2
    displayName: 'Signing output files'
    inputs:
      secureFileId: 'mycert.pfx'
      signCertPassword: '$(PfxPassword)'
      files: |
        **/MyOwn.*.dll
        **/Other.*.dll
        **/*.exe
      timeServer: 'http://timestamp.digicert.com'
      hashingAlgorithm: 'SHA256'

Now I need 3 steps instead of one (if multiline was supported). If needed, I can take some time and create a PR for that.

Additional SignTool.exe parameters for use with EV code signing certificates (on USB tokens)

We have been using this task for quite a while now and it works like a charm. Recently we switched from a regular code signing cert to an EV code signing cert, stored on a USB token. In order to access the certificate, a token password has to be entered each time a file is going to be signed. Using the "single logon" option of the SafeNet client, entering the password can be reduced to one time per session. However, this solution is still far from perfect. After some research I found this: Automate Extended Validation (EV) code signing

Using this approach it is possible to pass the token password to the SafeNet eToken as a parameter of SignTool.exe. This allows us to fully automate the signing process. In order to make this work, the cryptographic service provider (/csp) and the key container (/k) have to be specified as parameters for SignTool.exe.

For now we are using a private installation of a modified version of this task. I would really appreciate if you could add these two optional parameters so we can use the official release of your task again. Even if somebody is not using the mentioned approach, the added flexibility could be useful. I'll gladly provide a PR if you think, this feature would be helpful.

Add optional parameter for delay between signing files

We're using this task in one of our pipelines, and the list of assemblies to sign has grown over the past little while...to the point where we're running into the rate limit for Digicert's timestamp server.

@StefanKert I am in the process of writing a PowerShell script as a workaround, but I thought I'd ask if you have the time to add an optional parameter that specifies a delay between signing requests.

I can attempt the change myself and submit a PR, but it might take me some time. I am well-versed in TypeScript, but I haven't worked with Pipelines Tasks before, so I'm not sure how to test any code changes.

Thanks!

Debug

Hello, would that be possible to add the "/debug" option to use within this plugin and signtool.exe?

Thank you

TypeError: Path must be a string with TFS 2017

Working with TFS 2017 Update 3 I get the error below.

Seems it does not resolve something.

TypeError: Path must be a string. Received undefined
at assertPath (path.js:7:11)
at Object.resolve (path.js:186:7)
at Object.resolve (E:\BuildAgent\Agent3_work_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\node_modules\vsts-task-lib\task.js:581:37)
at SecureFileDownloader.getSecureFileTempDownloadPath (E:\BuildAgent\Agent3_work_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\securefiledownloader.js:47:35)
##[debug]task result: Failed
at SecureFileDownloader. (E:\BuildAgent\Agent3_work_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\securefiledownloader.js:24:42)
at next (native)
at E:\BuildAgent\Agent3_work_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\securefiledownloader.js:7:71
at __awaiter (E:\BuildAgent\Agent3_work_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\securefiledownloader.js:3:12)
at SecureFileDownloader.downloadSecureFile (E:\BuildAgent\Agent3_work_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\securefiledownloader.js:23:16)
at E:\BuildAgent\Agent3_work_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.1.0\index.js:33:54

Warning when using via ADO pipeline for older node version

When using the task via ADO pipeline it gives a warning about using node version 6
Also show a way to fix it

##[warning]This task uses Node 6 execution handler, which will be deprecated soon. If you are the developer of the task - please consider the migration guideline to Node 10 handler - https://aka.ms/migrateTaskNode10. If you are the user - feel free to reach out to the owners of this task to proceed on migration.

Should Code Signing be used in the build pipeline or release pipeline?

On the Visual Studio Marketplace, the description of Code Signing is this:

Build task for Azure DevOps that gives the user the ability to codesign assemblies and applications

I'm working on setting up my first Azure DevOps Services Pipeline for building and releasing a WPF application. I really would have thought Code Signing should be used in the release pipeline for ADS, not the build pipeline. Am I wrong about that?

Does it support MSI packages?

I was looking for a way to sign MSI package in DevOps, wondering if your tool supports that.

Add optional parameter for /ac in signtool

It would be nice to be able to use additional certs in signing files. I use this format:

signtool sign /t http://timestamp.digicert.com /ac additionalfile.crt /f mycert.pfx /p /fd SHA256

The current task works very well as it is. This would be great to add. Thank you for your time.

New requirements for signtool

When i tried to build today i got an invalid response from out timeserver. This seems to be caused by the windows-latest buildagent being upgraded to 2022. And the following can be read from the ssl.com timestamp server requirements for signtool.

Note: Be sure to use SignTool’s /tr option (specify URL of RFC 3161 time stamp server), not /t (URL of time stamp server), which is incompatible with SSL.com’s timestamp server.

Note: The /td option must follow the /tr option. If the time stamp digest algorithm is specified before the time stamp server, the default SHA-1 algorithm will be used. Windows 10 SDK, HLK, WDK, and ADK builds 20236 and above require use of /tr when timestamping. SHA256 is recommended over SHA1 for security.

And if i look in my buildlog the command that is run is the following:

D:\a_tasks\codesigning\2.2.0\signtool.exe sign /fd SHA256 /t http://ts.ssl.com/ /f D:\a_temp\codesigning.pfx /p *** D:\a\1\s\output\server\private\File.dll

I tried using the windows-2019 image instead but it still fails so it seems they updated signtool there aswell. So ill sign manually for now.

Is there a way to change this? Else it needs to be updated. Thanks

Support signing for files in $(Pipeline.Workspace)

Looks like the task is homed to the build sources directory whereas the new recommendation for signing pipeline artifacts in $(Pipeline.Workspace), which is one level up from the $(Build.SourcesDirectory).

Allow certificates to be appended

One of the options for the SignTool application is /as which 'Appends this signature. If no primary signature is present, this signature is made the primary signature instead.'. Having an option to append the signature or overwrite would be really helpful.

Sign multiple files

I cant seem to sign multiple files at the same time like i can with regular signtool, is there some special syntax or do i have to add a new task for each file?

I tried using the same syntax as signtool with only spaces between each file.

Thanks

Use a cert from the machine store. Without a password.

This tool seems to be designed to use a cert file with a password. Could a future version allow the use of a cert from the cert store? Specified by thumbprint?

This is how we are currently signing code, via a PowerShell script. It would be nice to have it handled with a build task like this, though.

How to delete an uploaded .pfx certificate

This is a question rather than an issue. When the extension uploads the .pfx file to a Secure File in Azure DevOps, how is this certificate ever deleted if we no longer want to use this extension?

Thanks in advance!

Tim

Allow exclusions in the signing list

It would be nice to provide a directory to sign all the DLL's at once and also tell it to not sign libraries that are not compiled by the pipeline. Like Microsoft libraries, NuGet packages, or other third party libraries that are used but not "ours". Thanks!

No signtool available

I'm trying to sign a msixbundle and am getting an error when trying to use the specific location of the signtool.

[error]There is no signtool available at C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe

Am I doing something wrong? I have checked and the signtool.exe is there.

Certificate path argument is not passed when using condition

I have successfully implemented the code signing task in a YAML-based pipeline like so:

- task: CodeSigning@2
  displayName: 'Sign Artifacts'
  inputs:
    secureFileId: 'File.pfx'
    signCertPassword: 'password'
    files: $(Build.StagingDirectory)\**\!(Newtonsoft*|System*|Microsoft*).+(dll|exe)
    timeServer: 'http://timestamp.digicert.com'
    hashingAlgorithm: 'SHA256'
    description: 'Description text'

In order to speed up our pre-merge validation builds, I recently added a condition to several of our pack/publish tasks so that they will be skipped when they are not needed. For the code signing task, the condition is implemented like so:

- task: CodeSigning@2
  condition: eq(variables.IsPR, 'false')
  displayName: 'Sign Artifacts'
  inputs:
    secureFileId: 'File.pfx'
    signCertPassword: 'password'
    files: $(Build.StagingDirectory)\**\!(Newtonsoft*|System*|Microsoft*).+(dll|exe)
    timeServer: 'http://timestamp.digicert.com'
    hashingAlgorithm: 'SHA256'
    description: 'Description text'

I have also tried using the eq(variables['IsPr'], 'false') syntax for the condition but the result was the same. In either case, when the IsPR variable is true, the task is skipped as expected. But when the IsPR variable is false, the task produces the following error:

2021-05-17T19:00:53.9717474Z Signing file: (Redacted filepath)
2021-05-17T19:00:53.9739929Z [command]C:\DevOps_Agent\_work\_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\2.2.0\signtool.exe sign /fd SHA256 /t http://timestamp.digicert.com /f "" /p password /d "Description text" (Redacted filepath)
2021-05-17T19:00:54.0136355Z SignTool Error: File not found: undefined
2021-05-17T19:00:54.0136734Z 
2021-05-17T19:00:54.0162483Z 
2021-05-17T19:00:54.0532759Z ##[error]Error: The process 'C:\DevOps_Agent\_work\_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\2.2.0\signtool.exe' failed with exit code 1
2021-05-17T19:00:54.0646031Z ##[section]Finishing: Sign Artifacts

The /f argument should have the path to the .pfx file, but instead it passes an empty string. If the condition is removed from the code signing task, then it runs successfully as expected.

Invalid Password

Hi there,
I get an invalid password error not matter how I specify my password. I tried parameter, variable (plain text), variable (encrypted), I even changed the password, but no lock.
What can be wrong?

`cmd: 'D:\a\_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.0.1\signtool.exe sign /fd SHA256 /t http://timestamp.digicert.com /f D:\a\_temp\HanakoPG.pfx /p *** D:\a\1\s\HanakoOnline\HanakoPG\Releases\setup.exe

2018-06-11T18:25:10.1899131Z ##[error]Command failed: D:\a_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\1.0.1\signtool.exe sign /fd SHA256 /t http://timestamp.digicert.com /f D:\a_temp\HanakoPG.pfx /p *** D:\a\1\s\HanakoOnline\HanakoPG\Releases\setup.exe

SignTool Error: The specified PFX password is not correct.
`

Time Stamp Server & Hashing Algorithm should/ideally could be configurable

I was wondering whether it would be possible to make the time stamp server url and also the hashing algorithm name optional as not everyone would want to use DigiCerts timestamp server and/or the sha256 algorithm.

In my particular case it is (by luck) exactly what I'd want, but seeing that it's "hard-coded" into the extension I wouldn't necessarily know/see when this would change so ideally the Extensions would/could make these two parameters configurable.

Should I give it a try (not having dabbled with vsts task extensions myself yet, but I might/could give it a try) or is it something you would need & want anyway and felt more comfortable doing it yourself?

Cheers and thanks,
-JB

Task is not available after installation

I just installed this extension on my on-prem ADS 2019.1 instance, but it's not showing up in the list of available tasks for my pipeline.

Is there something more I need to do? There doesn't appear to be any special configuration needed under the extension management page.

Code Signining Fails With Weird Error For MSIX Package Using Latest Version

Hey Stefan,

As of apparently late last week (Friday I believe), code signing using Sign Tool now fails using this task if I try to use the latest version of the sign tool on an MSIX package. The error is this:

Error information: "Error: SignerSign() failed." (-2146958839/0x80080209)

However, if I change the task to use the built in install tool, the signing finishes without any errors.

I am guessing using the latest must now pull in the Windows 10 2004 version of the sign tool but since my MSIX is targeting 1809 / 1903, it fails due to a mismatch?

I'm not sure if you think anything should be done about this or if we should just "deal with it" until 2004 is officially released. Either way, it may be worth having this somewhere in case anyone else building MSIX in Azure DevOps runs into this problem.

Does this support all the hosted agent?

My question here is does this build task support both windows and linux based hosted agents in Azure DevOps?Can we run this build task on any hosted agent?

Was not able to sign .crt file but I could sign the .pfx file

This was my error with no details.

Signing file: D:\a\r1\a_GENYX\drop\EasyPlexResultsNet48.Package_1.0.0.14_Debug_Test\EasyPlexResultsNet48.Package_1.0.0.14_AnyCPU_Debug.appxbundle
2021-11-11T02:05:23.3707501Z [command]D:\a_tasks\codesigning_0e0f3bf7-d96c-45d6-aa76-f9afb71fb77e\2.2.0\signtool.exe sign /fd SHA256 /t http://timestamp.digicert.com /f D:\a_temp\EasyPlexResultsNet48.Package_TemporaryKey.crt /p ausdx D:\a\r1\a_GENYX\drop\EasyPlexResultsNet48.Package_1.0.0.14_Debug_Test\EasyPlexResultsNet48.Package_1.0.0.14_AnyCPU_Debug.appxbundle
2021-11-11T02:05:23.6972993Z SignTool Error: An error occurred while attempting to load the signing
2021-11-11T02:05:23.6973851Z
2021-11-11T02:05:23.6974649Z certificate from: D:\a_temp\EasyPlexResultsNet48.Package_TemporaryKey.crt

%25 detected in ##vso command

all pipelines using this task are getting the below warning

##[warning]%25 detected in ##vso command. In March 2021, the agent command parser will be updated to unescape this to %. To opt out of this behavior, set a job level variable DECODE_PERCENTS to false. Setting to true will force this behavior immediately. More information can be found at https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/design/percentEncoding.md

Cannot sign executables from a different architecture (ex Mac or Linux)

I have a pipeline running and I am trying to use teh sign tool, I also specified use latest version.
I build the solution successfully for the three architectures.
When I sign the Win x64 it works flawlessly:

2021-03-04T01:04:49.5242411Z ##[debug]exec tool: C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe
2021-03-04T01:04:49.5243344Z ##[debug]arguments:
2021-03-04T01:04:49.5244079Z ##[debug] sign
2021-03-04T01:04:49.5248096Z ##[debug] /fd
2021-03-04T01:04:49.5248946Z ##[debug] SHA256
2021-03-04T01:04:49.5249722Z ##[debug] /t
2021-03-04T01:04:49.5250557Z ##[debug] http://timestamp.digicert.com
2021-03-04T01:04:49.5251880Z ##[debug] /f
2021-03-04T01:04:49.5252771Z ##[debug] D:\a_temp\XXXXXXXXXXXXXX
2021-03-04T01:04:49.5253607Z ##[debug] /p
2021-03-04T01:04:49.5255895Z ##[debug] XXXXXXXXXXXXXXX
2021-03-04T01:04:49.5259943Z ##[debug] /d
2021-03-04T01:04:49.5260826Z ##[debug] XXXXXXXXXX Win64
2021-03-04T01:04:49.5262277Z ##[debug] D:\a\XXXXXXXXXXXX\bin\Release\netcoreapp3.1\publish\win-x64\XXXXXXXXX.exe
2021-03-04T01:04:49.5263704Z [command]"C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe" sign /fd SHA256 /t http://timestamp.digicert.com /f D:\a_temp\XXXXXXXXXXXX.pfx /p XXXXXXXXXXXXXX /d "XXXXXXXX Win64" D:\a\1\s\XXXXXXXXXXXX\bin\Release\netcoreapp3.1\publish\win-x64\XXXXXXXXXXXXXXX.exe
2021-03-04T01:04:54.1700130Z Done Adding Additional Store
2021-03-04T01:04:55.6202589Z Successfully signed:

But when I try to sign Linux or Mac assembly is a different story:

2021-03-04T01:04:56.5277503Z ##[debug]exec tool: C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe
2021-03-04T01:04:56.5279370Z ##[debug]arguments:
2021-03-04T01:04:56.5280051Z ##[debug] sign
2021-03-04T01:04:56.5280960Z ##[debug] /fd
2021-03-04T01:04:56.5282003Z ##[debug] SHA256
2021-03-04T01:04:56.5283829Z ##[debug] /t
2021-03-04T01:04:56.5284551Z ##[debug] http://timestamp.digicert.com
2021-03-04T01:04:56.5285522Z ##[debug] /f
2021-03-04T01:04:56.5286054Z ##[debug] D:\a_temp\XXXXXXXXXXXX.pfx
2021-03-04T01:04:56.5286549Z ##[debug] /p
2021-03-04T01:04:56.5286998Z ##[debug] XXXXXXXXXXXXXXXXXXX
2021-03-04T01:04:56.5287472Z ##[debug] /d
2021-03-04T01:04:56.5287939Z ##[debug] XXXXXXXXXXXXXXXXXX
2021-03-04T01:04:56.5288513Z ##[debug] D:\a\1\XXXXXXXXXXXXbin\Release\netcoreapp3.1\publish\macos\XXXXXXXXX
2021-03-04T01:04:56.5305095Z [command]"C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe" sign /fd SHA256 /t http://timestamp.digicert.com /f D:\a_temp\XXXXXXXXXXXX /p XXXXXXXXXXXXXXX /d "XXXXXXXXXXXXX" D:\a\1\s\CoreAgent1\bin\Release\netcoreapp3.1\publish\macos\XXXXXXXXXXX
2021-03-04T01:05:00.6715286Z Done Adding Additional Store
2021-03-04T01:05:00.6821226Z
2021-03-04T01:05:00.6831197Z Number of errors: 1
2021-03-04T01:05:00.6831556Z
2021-03-04T01:05:00.6834624Z SignTool Error: This file format cannot be signed because it is not recognized.
2021-03-04T01:05:00.6835704Z SignTool Error: An error occurred while attempting to sign:
XXXXXXXXXXXXXX

I did specify to use latest version of the tool but it does not work.

secureFileId variable not supported when using jobs declaration in azure-pipelines.yml

We've used this task for quite a while very successfully but have encountered an issue in one very specific situation. We have a build pipeline that sets job specific properties to clean the workspace as shown here:

jobs:
- job: Build
  workspace:
    clean: all

If jobs: exists in the yaml then using a variable for the secureFileId property of the task is not properly handled. Our usage shown here:

  - task: codesigning@2
    displayName: Code Signing Assemblies
    inputs:
      secureFileId: $(CodeSigningFileId)
      signCertPassword: '$(code-signing-password)'
      files: '**/bin/**/$(buildConfiguration)/**/@(*.exe|*.dll)'
      hashingAlgorithm: 'SHA256'

We have other pipelines that do not have a jobs declaration which use a variable in this way and work fine. I get the following build failure immediately:

The pipeline is not valid. Job Build: Step codesigning1 input secureFileId references secure file $(CodeSigningFileId) which could not be found. The secure file does not exist or has not been authorized for use. For authorization details, refer to https://aka.ms/yamlauthz.

I've confirmed with log output that the content of the $(CodeSigningFileId) variable is the value I would expect and if I simply remove the jobs: declaration the task works with the variable.

I don't know that this issue is unique to the codesigning@2 task, but I'm hoping that someone might be able to give me some help on figuring this one out. Maybe there is something different about this task running within the context of a job?

Thanks for any help you can offer!

Add support for MSIX packages

Hello,
the current signtool isn't updated to the latest release, included in the Windows 10 1809 SDK. As such, it isn't able to sign MSIX packages, which is the successor of the AppX format.

Assembly still doesnt have strong name

Hello @StefanKert,

First of all, thank you for your tool! Can you please help me to understand the problem? Tool says my DLL was successfully signed but VS still telling me it's not. :(

Pipeline is: Build -> Sign -> NuGet Pack -> NuGet Publish -> Use as NuGet in other solution.

According to logs Sign and NuGet pack use the same assembly path