GPG-signed commits: a new exploit to consider

[Jim Hyslop]

There is a new repository attack that signed commits introduce. We 
should consider, this attack, if only to document it and consider best 
practises on detecting and reducing the risk.

The basic attack is to tamper with the GPG signature, with the goal of 
deliberately causing signature validation to fail. There are a couple of 
scenarios I can think of immediately:

A mischievous attacker simply wants to ruffle some feathers. No actual 
harm is done, it's simply a nuisance. Everything could grind to a halt 
until the most recent backup is restored (would this be classifed as a 
denial-of-service attack?). As a variation, a malicious hacker could 
employ this 'mischief attack' repeatedly, in the hopes that eventually 
people will ignore the error. Once that happens, the attacker can then 
slip in an actual exploit and users will assume it's the same annoyance.

In second scenario, the attacker is actually a trusted individual who 
has legitimate access to the repository. Mallory, a disgruntled 
employee, commits code that contains some nastiness hidden among valid 
changes. The committed nastiness is signed as usual. After the commit, 
Mallory modifies the signature embedded in the RCS file. If the 
nastiness goes undiscovered, Mallory gets away with it. If the nastiness 
is discovered, the GPG signature validation will fail, and Mallory can 
claim that the code she checked in did not contain the exploit, and 
someone else must have inserted the exploit, thereby invalidating the 
signature.

There are probably many other scenarios that we can invent involving 
signature tampering.

Signature tampering can be foiled (or at least discovered forensically) 
if the signature itself can be included in the 'loginfo' notifications. 
I would propose adding a '%g' format specifier to loginfo, which would 
insert the GPG signature. Thoughts? Comments?

--
Jim