Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

SignCheck doesn't seem to detect unsigned burn bundle engine

See original GitHub issue

It doesn’t look like SignCheck catches bundle installer engines not being signed (although it does catch MSIs not being signed):

#> Microsoft.DotNet.SignCheck.exe -i *.exe -r
Starting execution of SignCheck.

Results

[File] dotnet-runtime-3.0.0-preview9-19420-02-win-x64.exe, Signed: True
  [File] dotnet-host-3.0.0-preview9-19420-02-win-x64.msi, Signed: True
  [File] dotnet-hostfxr-3.0.0-preview9-19420-02-win-x64.msi, Signed: True
  [File] dotnet-runtime-3.0.0-preview9-19420-02-win-x64.msi, Signed: False [Error] HRESULT: 800b0100 (No signature was present in the subject)
[File] windowsdesktop-runtime-3.0.0-preview9-19420-02-win-x64.exe, Signed: True
  [File] windowsdesktop-runtime-3.0.0-preview9-19420-02-win-x64.msi, Signed: False [Error] HRESULT: 800b0100 (No signature was present in the subject)

There are unsigned files.
Total Time: 00:00:17.2721501
Total Files: 588, Signed: 500, Unsigned: 2, Skipped: 72, Excluded: 14, Skipped & Excluded: 0

@joeloff is this expected? Is it possible to check the engine?

Related: https://github.com/dotnet/core-setup/issues/7817. (Although Core-Setup ~doesn’t~didn’t have signing checks enabled yet, so having this feature wouldn’t have helped with that specific issue. 😄)

Issue Analytics

State:
Created 4 years ago
Comments:6 (6 by maintainers)

Top GitHub Comments

1reaction

joeloffcommented, Dec 20, 2019

Hmm, so we can definitely detect bundles, because SignCheck relies on it to decouple embedded installers, but I don’t think it strips the engine. We should definitely add that.

0reactions

dagoodcommented, Dec 2, 2022

The only error I know of that an unsigned engine can cause is a loudly failing installation attempt, seen in https://github.com/dotnet/runtime/issues/3742 and AFAIK never since. Maybe it’s a better use of time to make automated tests that try using the installers. (Or has this been done already?) It seems to me that would catch this issue and potentially more.

/cc @NikolaMilosavljevic @MichaelSimons