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:
> >>> 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.
> >
> Well, yes.  I may have phrased that badly, but what I was trying to
> get at is that a sufficiently up-to-date client should recognize the
> compromised hash and report the signature as invalid, regardless of
> whether it was once valid.

Yes.

> > It is also true that signing a delta with a compromised key that
> > has been revoked on the server could also be a flaw.
> 
> One that would also be detected with a client with an up-to-date key
> chain.

True.

> > I believe you will find that the version text is explicitly outside
> > of the text that gets hashed for signature validation.
> 
> Maybe - I can't recall off the top of my head, but if the data were
> incorrect then the client wouldn't be able to interpret the hashes
> correctly and it would be found to be an invalid signature once again.

The hash and signature types are encoded in the base64 text rather than
in the human readable parts. So, you may see 'Hash: xxx' but it is not
actually used by OpenPGP to do the comparison encryption.

> >>> 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...
> 
> You can live with it or you think I am right?  :)

I understand why you have chosen this as the default.

If someone has compromised the server you want it
to be in-the-face right away rather than potentially
ignored by the user.

I believe that we will see a number of GUIs that
sit on top of CVS just tell people to disable the
signatures to make things 'easier' or even
actively disable them because they won't have the
support initially to deal with signatures. Then it
becomes more difficult to transition to folks using
signatures as they become available.

For myself, I might have thought to allow for a
command-line switch to allow the checkout/update
of a particular file or directory on the command
line and included something in the CVS/Entries
file that indicated if the file had been verified
yet or not.

> I'm thinking it wouldn't be so bad to switch the
> default to "warn".

I'd like to see one release that allows users to
configure with a switch to tell if the client
should warn or fail when the server does not have
OpenPGP support and note in the documentation that
the default for 1.12.14 is warn and 1.12.15 will
be fail.

> I doubt you will be the only person to complain
> about this. Of course, how much flak will we get
> when a lack-of-server-signature-support warning
> scrolls off the top of the screen during a big
> checkout and some compromised code sneaks
> through. I'm not sure we can win with this one.
> :(

Yup, it has all the makings of a lose-lose kind of
situation.

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

iD8DBQFEYCoZCg7APGsDnFERAmiZAJkBYiSIpr906pdDLo8L8vBNJqMIfgCePTDD
R620KEXel21gSn/kwEhSAnw=
=6UKh
-----END PGP SIGNATURE-----