Как избежать разницы контрольных сумм при пересборке?

Question

[SHakeR]

Всем привет!
Помогите, плиз, разобраться со следующей проблемой.
Ввели у меня на работе систему контроля версий, пересборки и прочие радости. Это, конечно, здорово и радости моей не было предела, однако, параллельно создали группу, занимающуюся аудитом всей этой штуки. Аудиторы требуют, чтобы после каждой пересборки в Jenkins'е, все файлы релиза сопровождались контрольными суммами. Тут-то у меня и возникли проблемы, ибо я единственный использую .Net.
Собственно, проблема следующая: после каждой пересборки, у всех файлов релиза(dll, exe) меняется контрольная сумма.
Написал мелкую утилиту, занимающуюся чисткой PE заголовка от контрольной суммы и даты сборки - помогло частично, различий стало меньше.
Нашел исходники еще одной мелкой утилитины, чистящей файлы от MVID'а.
А вот как избавиться от последнего отличия - записи , сопровождающейся GUID'ом, который тоже меняется при каждой сборке? Подобный вопрос нашел на stackoverflow, но там ничего полезного в ответах.
Мозг уже не соображает как решить проблему. Спасите, плиз.

Answer 1

[aush]

the C# compiler was not designed to be a component of a security system, so don't use it as one

Eric Lippert

Вообще, то, что вы пытаетесь "вычистить" файлы от отличий, автоматически должно делать сверку контрольной суммы невалидной с точки зрения вашей СБ.

Comments

[SHakeR]

Ок, тогда как аудиторам подтвердить валидность релиза и соответствия исходников файлам релиза?
Тем более, другие отделы, занимающиеся, например, разработкой софта для Unix-систем обходят это ограничение замораживанием системной даты, что, в принципе, равнозначно тому, что делаю с помощью дополнительного софта.
P. S. Нашей СБ важны другие вещи ;)

Answer 2

[Виталий]

Чек суммы высчитываются не по "признакам" а по составу "массива байт", из которых состоит приложение и будет "иной" даже если изменить 1 байт, в этом и смысл чек суммы, то есть сделать "другое" приложение с "той же" чек суммой невозможно по определению, если конечно мы говорим о MD5 или подобной.

Comments

[SHakeR]

Так вопрос-то звучит по другому: есть исходники, в них не меняется ни один байт, собираем релиз и получаем контрольную сумму (КС1) всех составляющих. Далее берем все те же исходники(ни один байт, ни один символ не поменялся) и собираем релиз еще раз, получаем контрольную сумму (КС2).
КС1 и КС2 будут разными, так как во времясборки в PE заголовок exe'шников и dll записывается время сборки и контрольная сумма. Остальные байты exe'шника по идее должны быть одинаковы, исходники-то ведь не поменялись, правильно? А вот и неправильно! Как я понял, компилятор, например, в случае использования конструкции switch со стринговыми case'ами создает внутренний словарь(PrivateImplementationDetails) соответствия стринга ключу типа int, и присваивает этому словарю рандомный GUID при каждой пересборке.
Так вот вопрос-то в следующем: как скомпилить .Net приложение, чтобы контрольная сумма исполняемой части(отбросим PE-header) не менялась при перекомпиляции из одних исходников?

[Виталий]

@SHakeR: Ответ - никак, все равно при перекомпиляции байт код меняется, пусть даже часть метатегов останется не изменной добиться на .net того же массива байт после компиляции невозможно.

[Виталий]

Как вариант решения можно разделить по возможности приложение и его модули, и перекомпилировать только части приложения, но суть проблемы это не изменит.