1

This is assuming both computers have copied the exact same C# .NET project from one computer to the other. When you build the projects on both computers, are the executables exactly the same? If not, what's the difference?

The reason I ask is so source code can be validated as matching an executable. This is to assure users that are willing to build the program themselves that it's an exact match.

Phoenix Logan
  • 1,238
  • 3
  • 19
  • 31
  • What if one compiler has a patch that the other does not? Or if one has different versions of a library? – John Saunders Apr 11 '14 at 16:18
  • Okay, this is assuming the compilers and patches are the same as well. – Phoenix Logan Apr 11 '14 at 16:19
  • No, in fact is it guaranteed not to produce the same file even on the same machine. See [this](http://blogs.msdn.com/b/ericlippert/archive/2012/05/31/past-performance-is-no-guarantee-of-future-results.aspx). There are some ways in which you can try to handle this (see [here](http://stackoverflow.com/questions/2940857/determine-whether-net-assemblies-were-built-from-the-same-source)), but being able to compare them is not a designed for scenario. – Mike Zboray Apr 11 '14 at 16:19
  • If you think about a binary comparison I would be surprised if even two consecutive build on the same machine wouldn't be different because of the build time. Other differences will come in if the .NET assemblies differ. You should go for a version number instead, I think. – TaW Apr 11 '14 at 16:19

1 Answers1

2

To quote Eric Lippert:

No.

Well, that was an easy blog to write.

There is a GUID called the "Mvid" included when you build, to ensure that each build is different. Also, the C# compiler is not guaranteed to write the same instructions each time you run it. But in practice, in similar enough environments (for some definition of "similar"), I'd expect it to.

You can tell your users about this, and allow them to check for differences. If the only difference is in the Mvid, then they're done. If there are other changes, then they'd need to examine the functionality of the IL code to make sure that it is equivalent to yours. (this can be made easier with a decompiler like ILSpy)

If they're that paranoid, the best bet is probably just to build from the source themselves every time, and use their own build. But I do understand the usefulness of being able to audit it, e.g. you'd want to know that the official TrueCrypt or Bitcoin clients are legit.

shai tibber
  • 154
  • 11
Tim S.
  • 55,448
  • 7
  • 96
  • 122
  • Using signed binaries is the appropriate tool to prevent malicious code being edited into already compiled binaries from a trustworthy source, rather than decompliation and inspection of the IL. – Servy Apr 11 '14 at 17:13
  • @Servy You're right, but I didn't think that was the point of this question. Rather, it's confirming the trustworthiness of the source: that his binaries match his source code. – Tim S. Apr 11 '14 at 17:15
  • Well, a decompiled version is definitely going to have a lot of discrepancies with the source code, and if they're going to go to the trouble of comparing the decompiled version against the source by hand, they may as well just look for malicious stuff in the decompiled source and skip the actual source code altogether. – JLRishe Apr 11 '14 at 17:21
  • Thanks. The last paragraph is kind of where I'm coming from. My application is designed to be highly secure... and it will be open source, sort of like TrueCrypt/Bitcoin. – Phoenix Logan Apr 11 '14 at 19:45
  • I would like to add to this answer that we encountered a problem where our program couldn't recognise Hebrew characters and displayed such text as gibberish. This seemed completely random and we couldn't figure out when this happened and when it didn't. It eventually turned out that one of the programmers had a different system locale than the others and builds made on his computer were the culprit. – shai tibber May 30 '21 at 06:00