Re: [Cvs-dev] Re: [Cvs-test-results] CVS trunk testing results (BSDI BSD/OS)

[Derek R. Price]

Mark D. Baushke wrote:
> I suggest that --enable-maintainer-mode might care about this more than
> the general revision a user is using and might want to tell the user

Actually, I think `make distcheck' is probably a better place since the
version number would only really need updating prior to a release
(assuming as I am that having sanity.sh probe the internet would be a
bad thing), and a simple warning for all users from sanity.sh does not
seem harmful.

> Also, it should be up to the judgement of the cvs administrator if they
> wish to accept or reject signatures provided by a given version of

Well, the CVS administrator doesn't have much say about it, as things
stand, other than making sure a version of the CVS server is installed
than can record signature data.  I thought about making a provision for
having the server verify commits, and it might very well be useful, but
I haven't actually written anything yet.  As things stand, it is up to
each client to set whether they want their checkouts verified against
their key chain or not.

> OpenPGP. To that end, it may be desirable for the 'cvs sign' phase to be
> able to make a decision on the version of OpenPGP being used to do the
> signing.

Well, it can be set as a global option, a connection option, or an
environment variable.  Did you think the user needs more control than
this or were you referring to something else?

> (By the way, should 'cvs --help-commands' print out a line about
> the 'sign' and 'verify' commands?)

Yes.  I'll get to it with the rest of the sign and verify documentation.

> To that end, it may be desirable for both the client and the server to
> send the version of OpenPGP each is using in case a particular policy
> needs to issue rejections

I'm not so sure.  In at least one sense, signatures never have security
flaws, only verifications.  Or at least, if the signature was insecure,
a sufficiently up-to-date gpg should be able to spot it and report it as
an invalid signature during the verify stage.  There is version
information stored in the OpenPGP packets as well, if an actual OpenPGP
format is ever somehow deemed innately insecure, though it seems more
likely that individual hash algorithms, etc would fail and these are
also noted in the packet information as well, by necessity.

> If I need to use a number of different versions of CVS servers, why
> should I need to set CVS_VERIFY_CHECKOUTS=off to do a checkout from
> a cvs 1.11.x server using a cvs 1.12.13.1 client?

Because I opted for the more secure route as opposed to the one with
easier setup and decided that a naive checkout should fail without
signature data.  Setting CVS_VERIFY_CHECKOUTS=off in the environment or
in the CVSROOT spec simple enough and explicit enough that the user
would at least have to know they had disabled a security measure.

I'd feel fairly secure changing the default to `warn' instead of
`fatal', however this should never be auto-negotiated with the server
because a compromised server could then just tell the client it didn't
support signatures and the user might never notice verify-on-checkout
had been disabled.

Signing is auto-negotiated by default.  The CVS client will not attempt
to sign commits if the server does not report support for signatures.

> Does it make sense to consider adding command-line glue for
> CVS_VERIFY_CHECKOUTS to impact only servers that are able to support
> signauture so that I as a user could transition more easily among all of
> the different CVS servers they may be trying to use?

Again, no.  The user can change their own default in their environment,
but I'd rather not ship with a default mode that basically circumvents
most of what OpenPGP signatures were designed to prevent.

Regards,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot <http://ximbiot.com>!
v: +1 248.835.1260
f: +1 248.835.1263
<mailto:address@hidden>