Re: [task #4633] GPG-Signed Commits

[Todd Denniston]

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