Start-Process: This command cannot be run due to the error: The filename or extension is too long.

[aeisenberg]

I am getting the following error when I try to use this action. I'm pretty sure it's because the list of files to sign is too long.

Start-Process: This command cannot be run due to the error: The filename or extension is too long.

I am trying to split things up so that I can sign things in batches, but this is difficult to do since I don't really know what the threshold is, this clutters the workspace file since there are multiple steps each signing different binaries, and the number of files I need to sign changes over time.

Do you have any suggestions on what I can do to fix this?

[aeisenberg]

I realized I had to split the list of files into multiple calls.

[japarson]

Hi @aeisenberg, thank you for reporting this issue. How did you end up splitting the list of files into multiple calls? Would love to see an example.

Do you have some estimate what the maximum number of files that can be signed at once is? I'm wondering if it's actually the length of the call sent to Start-Process. Maybe there's some maximum number of characters allowed there. I'll do some testing.

It would be nice if the module handled orchestrating multiple calls to Start-Process instead of the user having to call the action multiple times. Just thinking of possible solutions - but need to investigate first.

[japarson]

From this thread, it appears the limit is around ~30k characters (depending on OS). Do you have any idea if you were approaching that limit with your call?

[aeisenberg]

Thanks for looking into this. I arbitrarily chose 4 batches and that seems to work (2 batches didn't work and I didn't try 3). I don't know how stable this is if we start increasing the number of files to sign.

          find unzipped -type f -iname '*.exe' -o -iname '*.dll' > files-to-sign.txt

          # Split the list of files to sign into chunks in 4 files.
          # This is necessary because the Azure Code Signing Action does not
          # handle large lists of files to sign.
          total_file_len="$(cat files-to-sign.txt | wc -l)"

          # Use +1 to round up and ensure there are exactly 4 files.
          file_len="$(expr $total_file_len / 4 + 1)"
          split -l $file_len -a 1 files-to-sign.txt files-to-sign-
          echo "::group::All files to sign"
          cat files-to-sign.txt
          echo "::endgroup::"
          for f in files-to-sign-*; do
            echo "::group::Files to sign $f"
            cat $f
            echo "::endgroup::"
          done

In all it's about 650 files and it looks like ~67300 chars. So, if the 30k limit is correct, 2 batches would be too few and three would be fine. Four batches gives us plenty of room to grow.

Also, it's not just the file paths that are counting towards the character limit in the call, but also all other parameters.

[aeisenberg]

From what I'm seeing, it looks like the problem is actually coming from AzureCodeSigning. Any retry logic and batching would need to happen there. Do you know if this project is open source and willing to accept contributions?

[japarson]

@aeisenberg Unfortunately, the project is not open-source and my team has no plans to make it open-source at this time. However, I have been working on a fix and plan to release it soon.

[aeisenberg]

Thank you.

We're also having challenges around single requests failing, which causes our entire workflow run to fail. Ideally, we'd like to see retries for certain kinds of errors. I'll raise a new issue for that.

[japarson]

@aeisenberg Please try the latest release and let me know if there are any issues: https://github.com/Azure/azure-code-signing-action/releases/tag/v0.2.26

[aeisenberg]

Thanks for looking into this. I'll try this out later today. Presumably, I should be bumping up the timeout value and this might help with some of the errors I'm seeing. And batch-size I can put at 165, which is roughly 1/4 of the total number of files.

[japarson]

batch-size is the summation of the lengths of file paths being signed. I would suggest leaving it at the default 10,000 and seeing how that goes before fiddling with the value.

[aeisenberg]

I've successfully signed all the files using the new action version. However, the time to sign was over 42 minutes. I mentioned here that previously, signing took anywhere between 7 and 38 minutes.

I'll try bumping the batch-size and see if that makes things faster. But with times all over the map, it will be hard to know if it's really faster or if it's a fluke without doing lots of runs.