Hi! On Fri, 2017-09-01 at 11:25:11 +0000, Holger Levsen wrote: > Source: dpkg > Version: 1.8.24 > Severity: wishlist > User: reproducible-bui...@lists.alioth.debian.org > Usertags: toolchain > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> during discussing #844431 it became clear, that some information about the > running kernel should be included in .buildinfo files, as this can affect the > build. It is actually not very clear to me. The examples provided there seem bogus: * Any build that relies on the currently running kernel for the resulting object is broken, and needs to be fixed. The host kernel might/should/will have nothing to do with the build one. * Builds that embed build kernel information should be fixed to not do that, as that information should be irrelevant for the generated object. * Builds breaking on kernel changing the version schema should only affect things such as kernel modules or similar, anything else is also broken. Any kernel version checks, if at all, should always be done at run-time. * Builds breaking due to disabled functionality in the current running kernel should be considered broken. In case of the test suite failing, that should be fixed to skip those tests gracefully. In case of the build system breaking, that should be reworked to not use that functionality (which I'd assume is unportable?). > For a start, including the output of "uname -s -r -v -m -i -o" (so basically > uname -a without the hostname) would be better than the current status quo, > though it would probably be even nicer to also include a hash of > /proc/config.gz or maybe even the whole thing. In addition to the above, I'm actually somewhat uncomfortable with this request, as it looks like a massive privacy leak. Compared to package lists and versions, which are actually requested by the package being built and might not have anything to do with the main system this build was being run on (say a chroot for example), or might get deleted immediately after the build. The kernel tends to be a system-wide resource, that even if upgraded does not mean it will be running (until a reboot). It's also somewhat common to have custom built kernels, with specific sets of additional patches, or specific modules/subsystems enabled. The version also pretty much encodes whether the running kernel is potentially vulnerable (until the next reboot) which would be a nice way to gather that information from the .buildinfo files for possible targeted attacks. So, the information proposed seems to be either redudant, because it's already part of the Build-Architecture field (-s, -m, -o); a major privacy leak (-r, -v); or not very helpful for reproducibility, as it would require the exact hardware to be able to reproduce the objects (-i). (Besides POSIX only specifies -m, -n, -r, -s and -v, so using anything else would be non-portable and a non-starter.) Given all the above, I'm inclined to just close the report? :) Thanks, Guillem
