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

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek R. Price <address@hidden> writes:

> Mark D. Baushke wrote:
> 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.

Good idea.

> > 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.

Okay.

> > 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?

I guess a connection option is good enough for what I was considering.

> > 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.

Actually, this is not necessarily true in the general case. If the hash
algorithm is compromised, it is possible that an entire class of
signatures could have security flaws from a trust point of view.

It is also true that signing a delta with a compromised key that has
been revoked on the server could also be a flaw.

> 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.

Revoked keys that are not part of the current keyring do not help the
user much.

> 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.

I believe you will find that the version text is explicitly outside of
the text that gets hashed for signature validation. There are format
revision fields in the packets too, but it does not relate to the
version of the protocol, but rather the version of the standard to be
used when deocding.

> > 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.

Okay, I guess I can live with it...

> > 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.

Okay.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEX8J6Cg7APGsDnFERAga9AJ9gB397gAOY6GokZUHS4AJZOOd90wCgh9wd
o1XwfDaoi52/FWa6Qzi0ki8=
=EQvQ
-----END PGP SIGNATURE-----