Re: Time to resurrect multi-key signatures in RPM?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux