Jim Hyslop wrote: > I've been thinking about the RCS Keyword Exploit ( > http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits_RCS_Keyword_Exploit > > ) > > Unless I'm mistaken, no keywords are expanded on check-in, they are > all expanded on check-out, correct?
True. > How about if CVS/Base contains the revision exactly as stored in the > RCS file (which will then allow the RCS keywords to be included in the > signature), and the server also sends a patch that expands the > keyword, which would be stored in a separate file, such as > .#filename.revision.kwd. Since these files contain only the patches > required (if any) to expand RCS keywords, the files will be fairly small. > > Thoughts? This was my original design actually, before I noticed the exploit, and this is exactly the situation that can be exploited. The point is that the server supplies the content of that keyword file and not all of it can be signed, so the content of your keyword info file, once substituted into the verified file, could compromise it. Read the scenario you linked to again. The revision metadata could be signed by the user, but some keyword content isn't known until checkout time, meaning that there is no one but the server to sign it and the main point of this GPG-signed commits exercise is avoiding a situation where a compromised server compromises the contents of the CVS repository. I was thinking about it too, and a combination of signed metadata (for log messages, author, date of commit, etc.) and maybe some simple verification that tags (for $Name$ keywords), for instance, only contained [a-zA-Z0-9_-] should be pretty safe, but I haven't done an exhausted analysis yet. Regardless, I don't think I want to do it in the first pass. It isn't necessary and the complexity of secure keyword expansion costs more than the feature is worth, to my mind. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
