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
• Epic: Deterministic build support sourcelink#601
• 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 and https://lists.debian.org/debian-devel-announce/2026/05/msg00001.html:

we've decided it's time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can't be reproduced [2] or existing packages (in testing) that regress in reproducibility.

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

SuSE: https://www.zdnet.com/article/suse-bets-its-future-on-digital-sovereignty/

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

Phase 1: Local - Reliance on wall-clock time, randomness/GUIDs and file-system-ordering

This first phase is about rebuilding .NET VMR on the same identical system at the same paths multiple times and getting bit-identical SDKs.

• Arcade
  • Follow Deterministic configuration when using NuGetPack arcade#16001
  • Set DeterministicTimestamps on nuget packages arcade#16787 Blocked by Re-enable support for deterministic pack NuGet/NuGet.Client#7020 and Taking a dependency on a recent nuget version? arcade#16623
  • Fix UpdatePackageVersionTask and ReplacePackageParts to keep already reproducible nuget packages reproducible. This doesn't actually seem to affect anything?
  • New SDL requirement: Enable deterministic builds arcade#15910
  • Use deterministic values for _BuildNumber arcade#16954
• 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. (fixed by Treat all ProjectRefs to SharedFx projects as PrivateAssets=all aspnetcore#64863)
  • RemoveSharedFrameworkDependencies task should create deterministic packages. Fixed by Treat all ProjectRefs to SharedFx projects as PrivateAssets=all aspnetcore#64863
• FSharp
  • F# compiler produces non-deterministic metadata #Strings heap layout fsharp#19732
• IdentityModel Extension
  • Set deterministic FileVersion for IdentityModel to match MSFT-shipped packages source-build-assets#1610
• MSBuild
  • Fix non-determinstic resources section in some deps.json files msbuild#12811 (fixed Non-deterministic resources section in .deps.json for csc, vbc and VBCSCompiler msbuild#12818 )
• 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#6963 (previously Ensure stable order of files in the nuget package NuGet/NuGet.Client#6649)
  • Re-enable support for deterministic pack NuGet/NuGet.Client#7020 (fixes Revisit deterministic pack NuGet/Home#8601. See also the spec at Add a design doc for deterministic pack NuGet/Home#14785)
  • Make PackageBuilder.CalcPsmdcpName deterministic NuGet/NuGet.Client#7410
• Roslyn
  • TODO
• Runtime
  • 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. This no longer reproduces.
  • Native ELF binaries shipped with .NET have non-deterministic GNU build-id runtime#128157 "Fix" is to use an identical native toolchain between builds
  • ELF .comment section in shipped native binaries is non-deterministic runtime#128158 "Fix" is to use an identical native toolchain between builds
  • DWARF .debug_str "producer" string in shipped artifacts retaining debug info is non-deterministic runtime#128159 "Fix" is to use an identical native toolchain between builds
• SDK
  • TODO
• source-build-assets
  • targetPacks/Directory.Build.targets invokes ILAsm without -deterministic, causing non-reproducible reference assemblies source-build-assets#1662
• 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 )
  • Remove use of [System.DateTime]::Now in build scripts
• vstest
  • File glob pattern in Microsoft.TestPlatform.Build.sourcebuild*.nuspec results in a non-deterministic order of files in the Microsoft.TestPlatform.Build nuget package Better fix belongs in NuGet.Client

Phase 2: Very host names, usernames and build paths

This phase is about rebuilding .NET VMR on different systems, and at different paths and getting bit-identical SDKs.

Nice-to-have

• Make NuGet.Clients' nupkg generation repsect SOURCE_BUILD_EPOCH for timestamps of embedded files. Part of Re-enable support for deterministic pack NuGet/NuGet.Client#7020
• 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?