RFE: .NET's build is deterministic/reproducible

[omajid]

Describe the Problem

Reproducible or Determinstic builds provide a very nice set of security advantages to a piece of software:

• Security and verification: It becomes possible to detect and deal with a whole new class of attacks in the supply chain - including on build servers. It becomes easier to verify items like SBOMs.
• Increasing user trust: Users can trust the binaries they have matches the sources, reducing risks of backdoors and other vulnerabilities.
• Auditing and Compliance: It becomes easier to verify that the sources and binaries match for compliance reasons.

For more details, see https://en.wikipedia.org/wiki/Reproducible_builds and https://reproducible-builds.org/

Describe the Solution

It should be possible to build .NET in a way that the build can be reproduced by others. The general guidelines for making this happen are described at https://reproducible-builds.org/docs/commandments/.

It's okay to requires some extra set up - such as an env var like SOURCE_DATE_EPOCH - to make this happen.

Ideally, this should be the default configuration of building. But a custom configuration, or custom build flags to enable this behaviour, would be fine as a starting point (and maybe even as end-point, depending on the number/complexity).

Additional Context

.NET:

• The https://github.com/dotnet/reproducible-builds project and it's READMEs such as Reproducible-MSBuild/README.md
• https://github.com/clairernovotny/DeterministicBuilds
• -deterministic compile option
• NuGet's [Spec] Deterministic Pack

Arch Linux: https://wiki.archlinux.org/title/Reproducible_builds

Debian: https://wiki.debian.org/ReproducibleBuilds

Fedora: https://fedoraproject.org/wiki/Changes/ReproduciblePackageBuilds and https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3OGIBZWPBB43QEVDXPEHNYEYJWMRPJ4E/

Red Hat: https://access.redhat.com/blogs/766093/posts/1976033

Timing

The primary driver for this from our side that Fedora is looking to start testing reproducible builds formally in 2025 (discussion). Fedora is going to report issues against software that doesn't comply with the reproducible-build guidelines by the end of 2025. Many other languages/runtimes - including Haskell, mingw and golang packages - are in the same position as .NET and are known to be non-reproducible at the moment. I don't expect Fedora to make reproducible builds a hard requirement in 2025.

Breakdown

Must-Have

• Arcade
  • Follow Deterministic configuration when using NuGetPack arcade#16001
  • Fix UpdatePackageVersionTask and ReplacePackageParts to keep already reproducible nuget packages reproducible
    • These use System.IO.Packaging which duplicates some of the nupkg creation logic from NuGet.Client. Particularly, it has no support for Deterministic like NuGet.Client already does.
  • New SDL requirement: Enable deterministic builds arcade#15910
• ASP.NET Core
  • Binaries like shared/Microsoft.AspNetCore.App/10.0.0-dev/Microsoft.AspNetCore.Components.Endpoints.dll and Microsoft.AspNetCore.Http.Connections.dll have a PE Time Stamp header that's different from build to build.
  • RemoveSharedFrameworkDependencies task should create deterministic packages.
• FSharp
• NuGet
  • Ensure stable order of entries in Content_Types.xml NuGet/NuGet.Client#6500
  • Ensure stable order of files in the nuget package NuGet/NuGet.Client#6649
  • Revisit deterministic pack NuGet/Home#8601
  • Wire up nuspec-based pack to deterministic mode NuGet/NuGet.Client#6580: Respect Deterministic msbuild property for generating nupkgs based on .nuspec files. This is needed to make source-build-reference-packages reproducible.
  • Need a new API to use a PackageBuilder with deterministic mode and stream NuGet/Home#14447
• Runtime
  • Ensure stable order in .deps.json file runtime#118185
  • Mono.Cecil.dll, Mono.Cecil.Mdb.dll, Mono.Cecil.Pdb.dll, Mono.Cecil.Rocks.dll contains many differences in the PE file itsef. The Import Tables are at different RVAs, size of .text is different, and .rsrc and .reloc are at different addresses.
• SDK
  • Many dlls in dotnet-watch (eg, DotNetWatchTasks.dll, Microsoft.CodeAnalysis.AnalyzerUtilities.dll) contain differences in PE data (RVAs, sizes, table addresses)
  • Microsoft.Diagnostics.NETCore.Client.dll contain differences in the PE itself: address of .text, address of Strong Name
  • Microsoft.Deployment.DotNet.Releases.dll contains differences in the PE itself: data directories are at different RVAs, etc.
• VMR
  • Flow Deterministic=true to repos dotnet#1618: Pass Deterministic=true property to all component repos. Deterministic=true is already the default.
  • Build nuget-client and vstest in deterministic mode dotnet#1584: Remove DeterministicBuildOptOut=true for vstest.proj and nuget-client.proj ( Why do nuget-client and vstest opt out of deterministic build? dotnet#1583 )

Nice-to-have

• Make NuGet.Clients' nupkg generation repsect SOURCE_BUILD_EPOCH for timestamps of embedded files.
• Don't skip .psmdcp files in eng/tools/BuildComparer/Utils.cs ?
• Remove exclusion for .psmdcp in test/Microsoft.DotNet.UnifiedBuild.Tests/NugetPackageContentTests.cs?

Questionable

• Set Deterministic=true at each repo-level? Deterministic=true is already the default at SDK-level.
• Add Deterministic support to System.IO.Packaging?

[omajid]

I added a bit more context and details around timing, as suggested by @MichaelSimons

[akoeplinger]

One place I'm aware of which uses the current date is CreateDebPackage.cs#L33 and BuildFPMToolPreReqs.cs#L81, but I think you don't use these tasks right?

[MichaelSimons]

One place I'm aware of which uses the current date is CreateDebPackage.cs#L33 and BuildFPMToolPreReqs.cs#L81, but I think you don't use these tasks right?

Correct, linux package creation is outside the scope of source build and is something distro maintainers are responsible for creating. This documentation aims to ensure consistency in packaging across distros.

[omajid]

I am adding support for nupkg to diffoscope here: https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/151

[omajid]

I have some cycles to look at this again.

I did a test run, and it turns out a lot of generic msbuild tasks (create files, compile dlls) create non-reproducible files where the difference is just the file modification time. Would it make sense to update core msbuild tasks like MakeDir to use SOURCE_BUILD_EPOCH (when set) as a source of creation time?