Re: [Gnu-arch-users] patch: automatic remove the corrupt revlib revision

[Thomas Lord]

andy:

 > Thanks for the patch!  I think this is safe for inclusion for the 
 > next release, unless if there is
 > any different opinion.
 > [....]
 >> -              {
 >> -                safe_printfmt (2, "corrupt library (failed inode
signature validation)\n   
 >> archive: %s\n    revision: %s\nYou should remove this revision from
your library.\n",
 >> -                               archive, revision);
 >> -                exit (2);
 >> +              { 
 >> +                rmrf_file(rel_peek_str (revision_dirs, 0, 0));
 >> +                continue;
 >>                }
 >>            }


It's your call, Andy, but if you're soliciting opinions: I think that's
a dumb idea.

One should always be extremely paranoid when injecting a call to
`rmrf_file' into Arch.   It's just about the most dangerous function
in the whole thing (and, indeed, is pretty darn dangerous).

Corrupt revision libraries should be a rare exception, not a rule.  If 
in some situation they are not, the bug is that they are not rare in 
that situation, not that the bogus revlibs are not automatically 
removed.   Look elsewhere for a solution.

In some situations, a corrupt revision library is a serious clue to a 
larger problem:  perhaps a disk has gone south in some unexpected way;
perhaps an intrusion has taken place.  In these cases, the bogus revlib
revision is a forensic clue and automagically removing it amounts to
"collusion to destroy evidence".

I think you are are dangerously close to the trap that a certain subset
of Canonical's awful hacking fell into:  

(1) some awkwardness is noted
(2) a solution is proposed that eliminates the awkwardness in 80% of 
    the cases
(3) that gets implemented

(To really do the Canonical number you'd have to add "(4) Point at Tom's
resistance of the 80% solution as reasons to beat him down still
further")

The problem, as I see it, is *roughly* described this way -- this is 
pseudo-quantization, not real quanitization:

The goodness of an 80% solution is:

   value-of-expected-consequence * .8

The badness is:

   cost-of-bad-case-consequences * .2


The overall value of an 80% solution is:

   expected-case-value * .8 - bad-case-cost * .2

In this case, you're solving a problem that should never occur
in the expected case.  Therefore, the solution you are thinking of 
merging has, from my perspective, negative value.  It's just icing on 
the cake that, when the problem occurs, the evidence you're proposing
to destroy is valuable.

-t