标签: binary-reproducibility

我正在搜索是否可以构建相同的Linux Kerneltwice(相同的源,相同的环境,相同的选项,相同的编译器)并获得相同的校验和.谁知道怎么做？

有没有办法强制相同的代码在Visual C++中生成相同的二进制文件？关闭PE中的时间戳或强制PE中的时间戳为某个固定值,换句话说？

当我使用c ++编译器构建项目时,如果源代码中没有更改,我可以确保生成的二进制文件不受影响吗？看起来每次我重新编译我的源代码时,二进制文件的md5校验和都会受到影响.编译的时间是否会以某种方式影响生成的二进制文件？如何生成可重复的编译结果？

出于二进制/源代码验证的目的,我希望能够在相同的计算机上相隔两周进行两次编译并使二进制文件相同,从而通过一些校验和测试.

到目前为止,我发现很可能时间戳将由编译器写入二进制文件.我可以通过对每个msdn文章的dumpbin/rawdata结果进行比较来解决这个问题.

http://support.microsoft.com/kb/164151

然而,垃圾箱结果在十几个地方仍然不同,差异似乎仍然是某种时间戳(例如从A1 73变为C4 76).

我假设这是delphi编译器放入代码/数据部分的时间戳,但我无法找到这种情况发生的位置或如何将其关闭.摆弄各种编译器/链接器选项并没有改变这种行为.

任何帮助将不胜感激.

根据我的经验,重新编译同一Android应用程序的源代码不会每次都生成相同的二进制文件.可重现的构建对开发人员非常有用,但我认为可重现的构建过程最重要的好处是安全性.在开源Android应用程序中,我们如何验证生成的二进制文件(.apk)是否真的是根据已审查的源代码编译的？有没有办法从Android SDK或Java生成可重现的构建？

我需要发送一个python脚本的编译版本,并能够证明(使用哈希)编译文件确实与原始文件相同.

到目前为止我们使用的是一个简单的:

find . -name "*.py" -print0 | xargs -0 python2 -m py_compile

问题是这是不可重复的(不确定是什么波动的因素,但是2次执行不会给同一个python文件提供相同的.pyc)并迫使我们总是运送相同的编译版本而不是只能给出构建脚本给任何人生成一个新的编译版本.

有没有办法实现这一目标？

谢谢

我正在构建一个R包并使用data-raw和data存储预定义RxODE模型库.这非常有效.

但是,生成的.rda文件会在每一代都发生变化.某些模型包含R环境,序列化似乎包含"创建时间"时间戳.这意味着每次data/重新生成目录时,所有文件都已更改...

是否有某种方法可以将R环境的序列化修改为可重现？

storeFile <- function(file) {
  env <- new.env()
  fun <- function(x) {x+3}
  environment(fun) <- env

  save('fun', file = file, ascii=TRUE)
}

storeFile('fileA.rda')
storeFile('fileB.rda')
message("Files are identical? ", identical(readLines('fileA.rda'), readLines('fileB.rda')) )

我有一个版本控制下的程序经历了多个版本.今天出现了一种情况,有人以某种方式设法指向程序的旧副本,因此遇到了已修复的错误.我想回去,只删除程序的所有旧副本(保持它们是一个公司策略,可以在版本控制之前发生,并且不再需要)但我需要一种方法来验证我可以生成完全相同的可执行文件,比说"旧版本来自此提交,因此这个应该是相同的"更好.

我最初的想法是简单地MD5哈希可执行文件,将哈希文件存储在源代码控制中,并完成它但我遇到了一个我甚至无法解析的问题.

似乎每次生成可执行文件(方法:打开项目.文件>生成X.exe)时,它的哈希值都不同.我注意到,每当项目以看似随机的方式打开时,Visual Basic会混淆文件,但我认为这不会成为可执行文件,也没有任何证据表明确实发生了什么.为了防止这种情况,我尝试在同一个IDE会话中多次生成可执行文件并检查哈希值,但每次都是不同的.

所以那是:

1. 生成可执行文件
2. 生成MD5校验和: md5sum X.exe > X.md5
3. 验证MD5当前可执行文件: md5sum -c X.md5
4. 生成新的可执行文件
5. 验证MD5的新可执行文件: md5sum -c X.md5
6. 验证失败,因为计算的校验和不匹配.

我不了解MD5或VB 6生成可执行文件的方式,但我也没有与使用MD5的想法结合.如果有更好的方法来验证两个可执行文件确实是相同的那么我就是全部.

在此先感谢您的帮助!

我们有一些共享程序集,每晚都会自动构建.如果没有对源进行任何更改,我希望程序集二进制文件与先前版本完全相同.

但是,程序集之间似乎存在细微差别.

我已经做了一些努力来确定两个版本之间的区别.我曾经ildasm生成过il版本,并比较了生成的文本版本.唯一的区别(在IL中)是模块中的MVID(随机guid).

一些谷歌搜索告诉我模块版本ID由编译器生成,因此可以确定构建源,即使其他所有内容都相同.

此MVID在相同代码的构建之间创建人工差异,并对所得到的程序集进行人工检查.

是否可以将MVID提供给C#编译器？

在 $DAYJOB，我正在尝试使用reproducible-builds.org中的提示来实现可重现的构建，以便更轻松地调试已发布的软件，而我们的构建服务器上不再有完整的调试版本。

在 GCC 中使用-ffile-prefix-map=/path/to/build=src选项来避免泄漏内部文件路径确实有助于使一些错误消息更清晰，但在使用 GDB 时确实会产生问题。我位于 /path/to/build/some/binary/ 并在 /path/to/build/lib/cclib/ 中命中断点：

Breakpoint 1, [...]
at src/lib/cclib/eventloop.cc:154
154    src/lib/cclib/eventloop.cc: No such file or directory.
(gdb)

作为解决方法，我可以符号链接src到构建树的根，但是有没有更好的方法来确保 gdb 理解映射？

构建相同的项目(没有任何更改)会生成二进制不同的 exe文件:它们的一些小区域是不同的.空项目,版本信息(以及每个构建的自动增量)已关闭.

为什么会这样？是否有可能让delphi为同一个项目生成二进制相等的文件？