opentelemetry-dotnet
opentelemetry-dotnet copied to clipboard
open-telemetry
OpenTelemetry.dll and OpenTelemetry.Api.dll are unsigned
Bug Report
List of NuGet packages and
version that you are using (e.g. OpenTelemetry 0.4.0-beta.2):
OpenTelemetry 0.6.0-beta.1
OpentTelemetry.Api 0.6.0-beta.1
Runtime version (e.g. net461, net48, netcoreapp2.1, netcoreapp3.1, etc.
You can find this information from the *.csproj file):
net472
Symptom
OpenTelemetry.Api.dll and OpenTelemetry.dll aren't signed.
What is the expected behavior?
The dlls are signed with sha256.
What is the actual behavior?
Dlls are signed with a code signing certificate.
Reproduce
right click on the dll in windows, and expect to see a Digital Signatures tab, or run: Get-AuthenticodeSignature opentelemetry.dll
and note that the Status is NotSigned.
Additional Context
Slack discussion on the same topic : https://cloud-native.slack.com/archives/C01N3BC2W7Q/p1647409842604329
Np update on this yet, and hence no ETA.
Adding some details - "signing" could refer to many different things for OpenTelemetry .NET project:
- ✅ 1. Whether the NuGet packages are digitally signed.
- ✅ 2. Whether the .NET assemblies are strong-named.
- 🛑 3. Whether the DLL files are signed.
PS > Get-AuthenticodeSignature OpenTelemetry.dll SignerCertificate Status Path ----------------- ------ ---- NotSigned OpenTelemetry.dll
For 1), when the OpenTelemetry .NET maintainers publish NuGet packages to nuget.org, the packages are automatically signed by nuget.org. This can be used to verify the integrity of the NuGet packages (and the files included in the packages).
For 2), all the assemblies generated from the OpenTelemetry .NET release build are automatically signed using a self-signed certificate. This can be checked by using the Strong Name Tool. Note that the strong name signing is not intended for security purpose - "Do not rely on strong names for security. They provide a unique identity only." "If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system."
For 3), currently the DLL files are NOT signed. A possible solution would be sigstore, which is making good progress:
- https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73
- https://blog.sigstore.dev/dont-panic-a-playbook-for-handling-account-compromise-with-sigstore-ee299dca5144
However, deciding the root cert, and figuring out the cert management/renew/revoke process could take time.
Here is my proposal:
Before OpenTelemetry .NET officially signs the DLL files, users are advised to do their own signing after verifying the integrity of the NuGet packages (using the NuGet signing, as mentioned in 1).
Even after OpenTelemetry .NET officially signs the DLL files, users should carefully review the cert trust chain and decide what's the best security model.
Before OpenTelemetry .NET officially signs the DLL files, users are advised to do their own signing after verifying the integrity of the NuGet packages (using the NuGet signing, as mentioned in 1).
One of the challenges with relying on this approach is that the nuget.org package signature doesn't say anything about the provenance of the DLL, only that the nupkg was served via nuget.org. An unauthorized actor could get access to publish to nuget.org on behalf of OpenTelemetry, via something similar to what happened with npmjs.org in the past.
For users to authenticode sign the DLLs, that breaks the Nuget.org signature (again providing a break in the provenance chain of the package and an opportunity to inject a malicious DLL).
In theory a signature from a cert issued by sigstore should be fine. I'm not aware of any reasons that this would be incompatible with Windows' AppLocker / Code Integrity policies.
Related to https://github.com/open-telemetry/opentelemetry-collector-releases/pull/207.