[Reproducible-builds] [Reproducible-commits] [notes] 01/01: add new issue, randomness_in_gnu_build_id and, so far, two packages affected by it: encfs and bacula

[Jérémy Bobbio]

Holger Levsen:
> On Samstag, 7. Februar 2015, Jérémy Bobbio wrote:
> > Build ID differs because the content of the binary
> > on which it has been calculated differs [1]. It's only random if there is
> > randomness in the content.
> 
> ah!
> 
> > Just writing “randomness_in_gnu_build_id” is equivalent to “something is
> > different” between the compiled binaries. Not a good categorization.
> 
> Yes, but https://reproducible.debian.net/dbd/encfs_1.7.4-5.debbindiff.html 
> doesn't show any other difference, same for bacula. So is this a bug / missing 
> feature in debbindiff?

No, it has nothing to do with debbindiff. You can't see what differs in
debbindiff output because what lands in the package is not the original
binary. What lands in the package has gone through strip.

This is actually mentioned in
https://wiki.debian.org/ReproducibleBuilds/Contribute#Inventorying_issues

Comparing packages built with `DEB_BUILD_OPTIONS=nostrip` can help.

For encfs, I assume the source of the problem is `-flto`, as set in
`debian/rules`:
https://sources.debian.net/src/encfs/1.7.4-5/debian/rules/

`-flto` will make GCC link to .o with random file names. The name gets
written in debug sections. To solve this, a patch to GCC will probably
be needed to make it output stable file names.

> Maybe the issue title is not helpful, but to me it still seems like a 
> trackworthy category even or maybe especially as we dont know yet what it 
> is...
> 
> So maybe rename randomness_in_gnu_build_id to undefined_randomness_in_binary? 
> or ..._elf_binary?

I think it really is not helpful. It's like having a category
“needs_more_work_to_understand_the_problem”.

-- 
Lunar                                .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150207/7a937aa8/attachment.sig>