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:

> Larry Jones wrote:
> > Derek R. Price writes:
> >> Have you had a chance to try this patch out?
> >
> > No, not yet
> 
> Hi all,
> 
> I noticed that the only test that should fail using gnupg 1.0.3 is
> openpgp-5 and tweaked my original patch to set a var and only skip
> that test when this is detected.

Okay.

> I don't have a system with gnupg 1.0.3 here, and was about to commit
> this and let Larry's nightly testing catch any problems, when the
> following occurred to me (based on something Mark Baushke said to me
> earlier):
> 
> Given the sensitive nature of gnupg, do we really want to cater to a
> gnupg that is over 5 years old (it was released 2000-09-20) in the
> test suite?

Generally, no. We should not need to cater to ancient versions GnuPG (or
the commercial PGP or any of the other OpenPGP implementations that may
arise in the future.)

> I'm inclined to say no.  I'm actually very tempted to
> make the test suite fail completely when very old versions of gnupg
> are discovered, with some sort of warnings about the sensitive nature
> of gnupg and the frequency of serious security fixes in gnupg, but
> keeping our tests and warnings up-to-date might become a nightmare.

Agreed.

> Therefore, I came up with a documentation patch instead.  Both the
> most recent version of my patch to deal with GPG 1.0.3 and earlier as
> well as the documentation patch are attached.

Okay.

> Does anyone have any ideas about how to warn about old GPG's in a more
> general way, short of gpg --version and bumping some hard-coded rev
> when we notice updates or polling the gpg website for new release
> notices?  Perhaps a target that only runs with
> --enable-maintainer-mode (better yet, as part of a maintainercheck or
> the distcheck target) that polls gnupg.org for the latest release and
> warns if the "latest gpg" version number is out of date?  

In general, it is not possible to know if a '1.2.3-99' version of GnuPG
contains all of the needed security patches for GnuPG 1.4.3 or not. So,
it may be that some GNU/Linux distributions continue to ship patched or
forked versions of GnuPG that are completely adequate.

For example, from a security point of view 1.4.2.2 contains all security
fixes to GnuPG. The latest version, GnuPG 1.4.3 contains some new
enhancments that are nice to have, but a client or server could still
be using 1.4.2.2 without any real problems.

Also, given the plethora of distributions, there are lots of variations
on gnupg 1.x.y-n.m distributions that may contian patches to fix the
same vulnerabilities that the 'latest' version of GnuPG provides while
keeping to the older and less volatile releases from a feature point of
view.

> Am I going overboard?

Not really, but I am not sure a static check when CVS is built or tested
is sufficient in the general case.

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
what revisions have been found and point to web sites like gnupg.org,
rpmfind.net, pgpi.org or any others folks might know to help them make
a more informed choice about the version to use.

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

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

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

All of this said, there are a few questions worth asking about the new
mode.

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?

Using a top-of-tree cvs executable against the
address@hidden:/cvsroot/cvs repository which is running
1.12.9, I can get doing a 'cvs update base.c' to pick up the last change
that went into the CVS sources.

cvs [update aborted]: No signature for `base.c'.

message unless I specify CVS_VERIFY_CHECKOUTS=off in my environment.

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?

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

iD8DBQFEX42NCg7APGsDnFERAqPCAJ9KdcJPXBawy7n3lWoO9JMhDYYAUACdHnJ6
DJGQe5BJPhJc60vDkuuHO90=
=xMFy
-----END PGP SIGNATURE-----