NuGet package ships an unsigned LibCecSharp.dll

[opdenkamp]

LibCecSharp.<version>.nupkg contains lib/net8.0/LibCecSharp.dll with no Authenticode signature. Checked on the 8.1.6 artefact — the PE Certificate Table data directory is empty (rva=0 size=0).

Why

Two things combine:

• cmake's LibCecSharp target runs dotnet pack during the build, while create-installer.py's sign_binaries() runs after the build and before makensis. So even on Windows the assembly is packed before anything signs it.
• The nupkg that actually reaches a release is built by the Linux leg — it is archived only inside libcec-dotnet_<version>_all.deb (usr/share/libcec-dotnet/), where no Authenticode signing exists at all.

Impact

Low. The package published to nuget.org is author-unsigned, but nuget.org repository-signs everything it accepts, so it installs and validates normally. It is also byte-for-byte what the libcec-dotnet Debian package has always shipped, so this is not a regression — it was simply never noticed before the package was published to a registry.

Possible fixes

• Sign the assembly before dotnet pack on Windows, and archive that nupkg as a build artefact so the release uses it instead of the one from the Debian leg.
• Or leave it author-unsigned deliberately and record that decision, since repository signing already covers integrity for consumers.

Worth deciding before the next binding is published to a registry, so all of them behave the same way.