On Thu, 2008-08-28 at 21:15 +1000, Bojan Smojver wrote: > But look, it is obvious that we (and by this I mean myself and the > majority of people in the thread) have fundamentally contradicting views > about this, so let's agree to disagree, OK? I don't want to drag this > forever. > > Consider my proposal withdrawn. Even if it looks differently, I've not been trying to shoot anything down -- I'm just not that good at phrasing criticism so that it's received as constructive... Let's see if I can add something positive: On Thu, 2008-08-28 at 23:25 +0000, Bojan Smojver wrote: > David A. Wheeler <dwheeler <at> dwheeler.com> writes: > > > Unsurprisingly, it requires determinism (e.g., recompiling the same > > program with the same compiler, on & for the same architecture, > > produces the same binary). The exact build state, not only the compiler, would have to be replicated for that, as there could be code inlined from headers etc. that influences what ends up in the binary. E.g. when building, save info about all installed packages (envr, md5sums, maybe even rpm-verify it for cross-checking?). Build "reproducers" would have to use the exact same versions for reproduction attempts. Keep in mind that this can lead to false negatives, i.e. if all reproducers use the same compromised compiler package that someone managed to sneak in -- this could realistically only show attacks on the build system itself. I'm not sure how to tackle that, perhaps by employing a not so rigid setup where all reproducers would _not_ use the exact same versions, but the process would not immediately block shipment, but flag differences so people can look into them. > As you say: > ----------------- > $ # If a.out and a.out.saved are always identical (except internal > $ # timestamps, if any) then the compiler is deterministic. > ----------------- > > And I could almost swear it is also possible to (automatically) edit binaries > that are different due to different environments (i.e. think things that embed > uname -v, perl -V etc.) so that a baseline is established and _then_ > checksummed, giving the correct (i.e. relevant) comparison. I think that's a bit dangerous as malicious code could be designed in a way that it's edited out before checksumming (make it look like you've incorporated the kernel version). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
