On Fri, 07 Mar 2014 14:45:01 +0100, Kern wrote in message <[email protected]>:
> On 03/07/2014 01:13 PM, Arnt Karlsen wrote: > > On Fri, 07 Mar 2014 11:41:25 +0100, Kern wrote in message > > <[email protected]>: > > > >> On 03/07/2014 01:32 AM, Arnt Karlsen wrote: > >>> On Thu, 06 Mar 2014 13:03:04 +0100, Kern wrote in message > >>> <[email protected]>: > 5. Based on the fact that the Bareos Swiss lawyer has *everything*, > the judge ruled that the notification was complete. > 6. Bareos retains their comment on their website. ..right, and you're both playing Crimean Standoff there. ;o) > >> Checksums would not be of any use in this case. > > ..read "checksums" as "tests the jurors can easily do themselves", > > such easy test would be useful if we had them now. > Yes, I agree that would be useful, and I will not complain if > you succeed in doing it. > > However, permit me to suggest an alternative strategy that > might prove useful. > > First my assumptions that may not be valid or may be hard to do: > 1. Your goal is to make sure the "vendor" doesn't have any > additional functionality in his binary that is not present in the > distributed source code. ..or bugs, both functionality and bugs are features. > 2. You can require the "vendor" to release the binaries with > debug symbols turned on or if they are stripped they must > be done in a way that they can be re-integrated as with rpm debug > packages. ..a better approach is have the gcc etc compiler folks solve this in a way that keeps software vendors happy, and makes jurors etc happy. E.g. by making checksum lists, settings etc, and compile logs, part of the standard compilers default release settings. ..this would set up a nice trap on violators, "I found a binary and checksummed it, do you have the source and the build recipe (and the checksum list)?", where you the decent vendor responds "Here: $url", and where the bad guys needs to respond as promptly with a slick story that starts with "Here: $url" and where said url needs to have the source, checksums, build scripts etc etc right (or "right") to produce "OK"s all the way down whenever some dumb juror tries to check the stories he is being told. > 3. You can require the *exact* build scripts that they used > to produce the binaries (i.e. which compiler, optimization > options,... ..yup. > 4. Now at that point, one could (as a fairly big project) write a > program that breaks the binary up into subroutines and puts them into > some human readable form (assembly language, or perhaps reconstructed > C, C++). Call it the "reconstructed source". ..this I feel is moving towards forensics and investigations, useful, but not what I feel jurors should be doing. ..jurors often struggles to understand whether or not and how "tech" babble laced evidence matches the story each law shark tries to push him or her to believe, and will want any easy test tool set to make sure the stories they are told, makes good common sense to them. > Now you can do a fairly high level comparison of the two programs on a > subroutine by subroutine basis (object file by object file or > whatever) to search and find any code that is included in the > distributed binary that is not in the distributed source. Comparing > the "reconstructed source" from the vendor's binary and a binary that > you build, could also then show up any major discrepancies or "code > that was left out of the distributed source". ..yes, this is useful, but the teeth in the GPL comes from copyright law, which is decided upon by jurors and judges, if their tool sets remains blunt, so will GPL's teeth. > Best regards, > Kern -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case.
