Re: Identical binaries from same source code
- From: Jon Skeet [C# MVP] <skeet@xxxxxxxxx>
- Date: Thu, 13 Mar 2008 15:36:19 -0000
<snamds@xxxxxxxxx> wrote:
Right. In that case, I don't think the question as originally asked
would actually help you. It doesn't help for you to be able to rebuild
the same source to the same binaries multiple times if the homologating
company then uses a different mechanism to compile your code.
This is not a problem. We provide the compiler and method of
compilation to the homologation company. They first validate the
method of compilation.
In that case, would it be possible to have a cache of source code +
binaries, so that it always consults the cache before bothering to
build at all?
The best way of making sure that you get the same result is not to
rebuild unnecessarily :)
I do understand that that may not be feasible, however.
Now, three questions arise:1 and 2 -> Yes, because of my prior explanation.
1) If you send the same source to the homologating company twice, do
*they* end up with the same binaries?
2) Are they happy to share their homologation methods with you?
3) If you can produce the same binary as the homologation company,
doesn't that defeat the purpose of the legislation? I would expect the
point to be similar to crypto-signing - e.g. to guarantee that the
homologation company has the original source code.
No, because we must explain what we have post changed in the binary
and they validate the method. The don't have to believe in what we
say, they can check the method.
I'm sure this is the way we must do things. The problem is that this
is our first project with C#. Before, with C++ we only had to clear
the timestamp of the binary.
The CLI spec gives details of the PE format, but it's possible that
there are some implementation-specific fields that are being generated
every time.
By the way, I wouldn't set the GUIDs and times to zero - I'd choose
appropriate values and always reuse those.
Note that if you sign your assemblies, all of this editing will
probably (hopefully, even) invalidate the signature - in which case the
suggestion at the top of this post is probably the only practical one.
Would it be possible to make the CRC comparison ignore specific parts
of the binaries, so long as you could explain that they don't affect
the behaviour of the code? That way we wouldn't need to work out what
values to use for the new binaries, just reasons why they're not
important.
--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
.
- Follow-Ups:
- Re: Identical binaries from same source code
- From: snamds
- Re: Identical binaries from same source code
- References:
- Identical binaries from same source code
- From: tararot2
- Re: Identical binaries from same source code
- From: Lasse Vågsæther Karlsen
- Re: Identical binaries from same source code
- From: snamds
- Re: Identical binaries from same source code
- From: Lasse Vågsæther Karlsen
- Re: Identical binaries from same source code
- From: snamds
- Re: Identical binaries from same source code
- From: Jon Skeet [C# MVP]
- Re: Identical binaries from same source code
- From: snamds
- Re: Identical binaries from same source code
- From: Jon Skeet [C# MVP]
- Re: Identical binaries from same source code
- From: snamds
- Identical binaries from same source code
- Prev by Date: Re: Factory method question
- Next by Date: Re: Simple String split
- Previous by thread: Re: Identical binaries from same source code
- Next by thread: Re: Identical binaries from same source code
- Index(es):
Relevant Pages
|