Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

[Vagrant Cascadian]

On 2017-09-02, Holger Levsen wrote:
> On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote:
>> > 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.

Agreed.


>> * Builds that embed build kernel information should be fixed to not
>>   do that, as that information should be irrelevant for the generated
>>   object.

Agreed... *but* it can be hard to know that's the reason if you don't
know that the kernel versions differ.

While the .buildinfo file primary purpose is to be able to reproduce a
build, it has a useful secondary role of documenting part of what might
be different about the build environments.


>> > 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).
>
> on reflection I agree that the privacy implications are too bad.

The including the build path also has privacy implications, but it can
be disabled from inclusion in .buildinfo, no?  What about including the
kernel if something like DEB_BUILD_OPTS="buildinfo=+kernel" ?


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20170906/4ef41d63/attachment.sig>