Sylvain Beucler wrote: >I had in mind to sign what is stored in the RCS file, that is the >commit-time content minus EOL conversions under MS Woe. AFAICS, that >commit-time content is what you get using '-kb' later on. The verifier >would check the signature before to perform keyword substitution (I >assumed the client did the substitution, but maybe I'm wrong. In the >worst case the file could be checked out twice, one in -kb for >signature-checking and the other one with any keyword substitution). > >
I forgot you had specified that the "Header" information would also be signed. As long as anything that could appear in a keyword also appeared in the header, this is fine. >I think the user can be trusted for maintaining the keyring, but I >think a keyring could be specified, to avoid accepting signatures from >people who have nothing to do in the development of the current >repository. > > Perhaps the most generic thing to do would be to implement the gpg command as a template in a config file (or on the command line). Thus, --gpg-sign "/usr/bin/gpg --keyring XXXX --sign %s", could allow the user to set arbitrary settings, subbing the filename for %s? Something similar could be done for --gpg-verify. >So the only work to get a canonical version just before the commit is >to convert line endings on non-Unix platforms, except if we deal with >a real binary file. Even a wrapper should be able to reimplement that >transformation easily, shouldn't it? > > Yes. >The verification, if done by a wrapper, needs to checkout the file >twice (the normal checkout and the canonical/binary one), hopefully >this could be optimized with a builtin solution. > > Checking out the file twice is definitely wrong. A compromised server can serve the "correct" file for signature checking and a corrupted file for use. If keyword substitution is to be allowed, any data to be substituted into a keyword must also be signed and the client must do the substitution. >Is there something else than can change the content of a revision? Are >there server-side hooks that can modify the content of the file >itself? (as verifymsg does for the commit message?) > > There used to be a way to do that, and commitinfo probably could, but I think it is mostly disabled or not used because of other problems it caused (at the least, the committing user's sandbox becomes invalidated). >4) Where to store the information? > >If the signature can be added as a new field in the RCS file without >breaking backward compatibility, that would be great. The commit >message is subject to modification by the verifymsg hook, so it be >better to avoid it, I guess. The fact the commit log is changeable via >'cvs admin' is not really an issue, since it would allow later >additional signatures, though it would be better if such changes were >append-only. If we store the information somewhere else, then a new >'cvs admin' command would be needed so as to change the related >signature as well. > > Again, any allowed keyword substitution who's source data is not signed opens the client up to the attack I mentioned. In this case it would be the $Log$ keyword which could be used to insert arbitrary data. >Do you think it's possible and reasonable to store all the signatures >as a new RCS field? > > Yes. >I think a 'cvs' (or an 'update/co/export') option would also be >good. It needn't be default, and could be easily added to >~/.cvsrc. Another tool to apply batch validation would be needed as >well indeed. > > This would be nice. >Another configuration option would be to specify which set of >signatures you trust for a given repository. > > I like the idea of specifying a separate keyring via the gpg-verify template. This minimizes the amount CVS has to know about GPG. It would only need to know the (configurable) gpg-sign and gpg-verify templates and pass a path to a file to them. 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]> _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
