incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: key signing
Date Thu, 11 Oct 2012 16:14:34 GMT

I don't understand the supposed attack vector concerning the file digests being of no value
and the WoT being essential.

 - Dennis


So long as the digest value is obtained from a reliable read-only source, it doesn't matter
where the file comes from, the digest can be verified.  This will protect against and help
detect a poisoned mirror site or a third-party redistribution that substitutes an inauthentic
artifact.  That is, in fact, a very big deal and it defends against exploits that happen too

If the reliable read-only source is compromised, that means an adversary has managed to (1)
replace the file in Apache custody, and (2) replace the digest that applies to that artifact.
 (Or just replace the digest and make the authentic file look bogus and the poisoned downloads
look authentic.)  If substitution of the file-digest pair is achievable, providing a different
external signature can't be much harder, although the exploit might achieve the intended purpose
without that. Introducing a verifiable external signature that finds a counterfeit public-key
certificate on a key service may extend the ruse a little longer. 

The exploit continues until some Apache folk or security-proficient external party detect
(1) the substitution or (2) a counterfeit external signature or (3) confirms that the external
signature is not verifiable on the substituted file and digest pair.

I don't see the WoT as much of a factor if this exploit occurs.  It comes down to how quickly
the exploit is detected, the damage detected, and a mitigation put in place.  I assume that
infrastructure defense-in-depth measures have to expose the fact of an exploit, even if an
insider is involved.  At the worst, it might be necessary to recall a release.

This assumes that the exploit is by exploit against the read-only distribution material in
Apache custody.  

If the exploit is by tampering with a release prior to its approval, that is an entirely different
problem, since it means the digital artifacts have been approved as authentic.  Even so, I
think it is the trustworthiness committers, release managers, and PMC approval that matters
here, not the WoT, and that is bolstered by the Apache Trust Chain.  The WoT does not protect
against someone subsequently being revealed to have committed a bad act.  (The revocation
of trust and how it is noticed is an aspect of WoT that I have not investigated.)

-----Original Message-----
From: Nick Kew [] 
Sent: Thursday, October 11, 2012 06:46
Subject: Re: key signing

On 11 Oct 2012, at 09:57, Noah Slater wrote:

> On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew <> wrote:
>> You have to extend that assumption not only to our infrastructure but to
>> every proxy that might come between us and a user, and that might
>> substitute a trojan along with the trojan's own SHA1.
> The same reasoning holds for the .asc file.

Only if there are no WOT paths to improve confidence in it.

And only if noone ever detects the imposter, which is a lot less
likely with a trojan PGP key (someone in particular is being
impersonated) than a checksum (owned by noone).

Nick Kew

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message