Re: [libreplanet-discuss] How to verify a GPL binary - practically?

[Jamie Hale]

Thank you, that's what I'm looking for taken to the ideal, and something
I will consider using for my own projects.

For this particular problem, I'll try to build from source and
diffoscope it, but I'm not hopeful that anything useful will come out of
it. There are enough dependencies to make it painful.

I'll post anything useful I find though.

J

On 29/06/16 10:42 AM, Thadeu Lima de Souza Cascardo wrote:
> On Tue, Jun 28, 2016 at 07:50:30PM -0400, Jamie Hale wrote:
>> Forgive me if this has been asked before.
>>
>> I've purchased a copy of "ethOS", a GNU/Linux distribution that comes
>> ready to mine ether, the cryptocurrency that backs the Ethereum network.
>> The mining program bundled, ethminer, is distributed GPL.
>>
>> The distro owner claims that no modifications have been made to
>> ethminer, that he compiled from a certain label in a public repo.
>> Because of the possibility of backdooring the software and stealing
>> private keys, I want to confirm his statement. (Note: I am in no way
>> accusing him of doing anything like that! Just performing due diligence!)
>>
>> ... but I can't think of a way to do it.
>>
>> It looks like my only option to be safe is to download the same source
>> and compile it on my own and *not* use his. And hope it works even
>> though it's not the binary he's tested with.
>>
>> (I can't think of a way to reproduce a binary with the identical hash
>> without having access to the original build environment. Too many things
>> would have changed.)
>>
>> Is there another option I've overlooked?
>>
>> J
>>
> https://reproducible-builds.org/
>
> In the last few years, there has been an effort to provide reproducible
> builds inside many distributions. Most of the people involved in the
> project are also involved in Debian, but they are pushing this into
> other distros as well. I know Holger has given a talk to Fedora people
> at Devconf.cz and is going to give a talk at the OpenSuse conference as
> well.
>
> Some of the products of this effort include changes to the toolchain
> that builds software packages in order to remove some of the
> differences, like file ordering when packing and timestamps, some of the
> most common problems.
>
> You should build it from source code yourself, using most of the same
> dependencies as possible, and try diffoscope, one tool that they have
> produced that will try to summarize the changes for you. So instead of
> using something like cmp that will only tell you that byte XXXX differs,
> it will show you that timestamps differ, but there are no other changes,
> for example.
>
> It would be interesting to know the results of your efforts in this
> thread.
>
> Regards.
> Cascardo.