Time to resurrect multi-key signatures in RPM?
nils at redhat.com
Tue Aug 26 09:40:37 UTC 2008
On Tue, 2008-08-26 at 11:56 +1000, Bojan Smojver wrote:
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
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
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 Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils at redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
More information about the devel