On Tue, 2008-08-26 at 11:56 +1000, Bojan Smojver wrote: > Comments? I'm not an expert on these things, but I feel some flaws in your scheme. First, it relies on that building a specifically tagged package will always produce the same result. Others have already pointed out that some software embeds non-deterministic data in files. I'd like to point out additionally that the build dependencies aren't 100% deterministic as well: when you build a new version of a build dependency and build a dependent package soon afterwards, chances are high (enough) that some builders build against the new and some against the old package, which likely has an influence on the produced binaries. Should we ever employ optimization techniques like profile-based compilation, builds between separate build systems (that have different profile data) will inevitably differ. Second, it makes the update system more vulnerable to DOS attacks, insofar as it only takes an attacker to hack himself into one of the signatories to produce bad signatures on updates he wants to block (if they e.g. contain security fixes). The risk of this is at least proportionally higher with multiple targets to choose from (think RAID-0 and what it does to the probability of errors in such a set of disks). Third, unless a signatory runs his own build system to verify package builds (and disregarding my first point), his signature doesn't have much value as he has to rely on the checksum data provided by the package maintainer in his signed email -- which relies on the build system not being compromised to begin with. Then there's the additional burden on maintainers -- yet another bureaucratic hurdle. Note that I'd appreciate being able to have multiple signatures on a package, but I don't think it helps us with this issue. 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
