Yes, but you can just generate *new* keys (with the same name), which
will invalidate all the certificates, but they aren't valid anyway
(well, they were valid when they were signed but they can't be verified
now, which is your problem)
Once you have the new keys then you can just re-sign all the certs, and
then monotone will stop complaining.
If you aren't interested in maintaining the history of the other keys
then you could just re-sign with your normal key (my program can't do
it directly like this atm but it wouldn't take long to change). It
mostly depends on your needs. Reading your OP the other people who
signed certificates are no longer in the picture, so the issue of
tracking 'who was responsible for this revision' for historical stuff
may not be as important (to you) as the new stuff you plan to do as
soon as it will stop complaining every time you invoke mtn. :)
Essentially we lie to monotone to get it to believe something that we
know is true.
On 9 Oct 2007, at 11:25 am, Benoît Dejean wrote:
Le dimanche 07 octobre 2007 à 04:31 +0100, Peter Stirling a écrit :
I believe I have something that can help you.
I wrote a lua program that:
Looks for revisions with 'bad' certificates (as reported by "mtn au
certs <rev>") which have private keys available to monotone
My DB is missing keys for which i don't have the private key :/
--
Benoît Dejean
GNOME http://www.gnomefr.org/
LibGTop http://directory.fsf.org/libgtop.html
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
