Derek Price wrote: > > Mark D. Baushke wrote: > <SNIP> > > + There is a need to deal with expired keys and revoked > > keys as well as with successor keys. > > Yes, again, this is in my design document, though I chose to deal with > expired and revoked keys by allowing users to resign old revisions if > they wish: > <http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits#New_Sign_Command>. > It should be fine to just leave old (expired/revoked/whatever) > signatures in place, and allow the newer signatures to provide > verification, but I also noted a -d option for the resign command to > allow expired/revoked/whatever signatures to be deleted. <SNIP>
What about instead of, or in addition to, what you are suggesting for expired/revoked signatures, the sig ring should keep data on when keys expired (already there correct?) or got revoked and thus CVS should flag new sigs with those keys after the expire/revocation to notify the users, but the old sigs should still be good/acceptable. Or have I just slipped of my rocker? -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
