RE: Win32 builds of 1.12.latest?

[Rob Clevenger]

I have some unofficial builds available at
http://www.robsite.org/prog/cvs/index.html

Rob


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of D. J. Hagberg
Sent: Friday, December 19, 2003 9:12 AM
To: [EMAIL PROTECTED]
Subject: Win32 builds of 1.12.latest?


Is anybody doing official or unofficial but known-working cvs executables 
for Win32 of the latest rev's of CVS?  The latest I can find on 
cvshome.org is 1.11.9.  That version seems to work OK with the server-side 
1.12.5 but I'd like to keep the versions in synch for my team.

If there isn't an official build, has anyone tried to cross-compile using 
mingw32 on Linux to build cvs executables for win32?

-=- D. J.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security audit?

[Larry Jones]

Eric Siegerman writes:
> 
> Now, I seem to recall that one of the big objections to pserver
> is that CVS "has never had a security audit".  Once the Savannah
> audit is finished, that objection goes away.  How will that
> affect peoples' level of confidence in pserver and the like?

The objection is that CVS was never *designed*, or even *intended*, to
be secure.  An audit will affect my confidence not one whit -- it's
sufficient to keep honest people honest, nothing more.

-Larry Jones

Like I'm going to get any sleep NOW. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Checksum failure: serious problem or not?

[Larry Jones]

Eric Siegerman writes:
> 
> Hmm, what would it take to convince you? :-)

A whole bunch of people to agree (vociferously) with you.

> I strongly agree with Jim.  Some more thoughts on how it could be
> improved:
>   - Saving the user's file as .# backup is the least it should
> do.  Better would be to abort the update, leaving the user's
> file unchanged.
> 
>   - Best of all would be to fall back to a merge instead of to
> the current overwrite.  This wins because it reduces the case
> to one the user is already familiar with -- saving the .#
> file falls out transparently (from the user's point of view;
> I don't know about the code's), and the error message can
> probably be eliminated after all.
> 
>   - Local mode should offer the same level of protection as does
> client/server.  (Even though the proximate reason that the
> error is detected in client/server (failed patch attempt)
> doesn't apply to local mode, the underlying error condition
> is just as severe, and just as worthy of action by either the
> user or by CVS.)

Feel free to submit patches.  The tricky part is that it's the *client*
that detects the problem.  The client doesn't have sufficient
information to do a merge (merges happen on the server), and there is no
client in local mode to do the detecting.  There are lots of "can't
happen" error messages in CVS, this one just happens to actually go and
occur from time to time.  :-)  (But it's still very rare.)

-Larry Jones

I don't think that question was very hypothetical at all. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security audit?

[Eric Siegerman]

[following up my own post; sorry]

On Fri, Dec 19, 2003 at 06:08:40PM -0500, I wrote:
> How will [a security audit having been done]
> affect peoples' level of confidence in pserver and the like?

In another thread, on Fri, Dec 19, 2003 at 11:18:57AM -0500, Jim.Hyslop wrote:
> Well, clearly pserver is not secure because the password is sent effectively
> in plain text [...]

Woops, I'd forgotten about that!  Ok, as regards pserver itself,
my question was pretty dumb.  But how about GSSAPI or Kerberos
with encryption?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS security audit?

[Eric Siegerman]

Just out of curiosity, is this rash of CVS security fixes coming
out of the savannah.gnu.org audit?

Let me be a bit of a gadfly: I presume the Savannah folks are
security-auditing CVS along with other relevent tools, even if
they aren't the source of the current bug reports.

Now, I seem to recall that one of the big objections to pserver
is that CVS "has never had a security audit".  Once the Savannah
audit is finished, that objection goes away.  How will that
affect peoples' level of confidence in pserver and the like?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Checksum failure: serious problem or not?

[Eric Siegerman]

On Fri, Dec 19, 2003 at 03:22:31PM -0500, Larry Jones wrote:
Larry> Eric Siegerman writes:
Larry> > 
Larry> > The "P" status and the "checksum failure" message should both go
Larry> > away.  (Patched and fully-refetched files should all be labelled
Larry> > "U".)
Larry> 
Larry> I might be convinced about "P" status (although, personally, I like it),

Hmm, what would it take to convince you? :-)  My main arguments
are:
  - User confusion; it's a fairly FAQ, and a needless one

  - The fact that CVS distinguishes "P" from "U" implies
(wrongly) that they're different in some important
source-controlish way -- commensurate with, say, the
distinction between "U" and "M", or between "M" and "C", or
between "A" and "?".  In fact, as far as source control is
concerned, "P" and "U" are identical.  In other words,
there's a layer mismatch.  The other codes all reflect
differences at the "source-control layer" (to rather stretch
the OSI model) but "P" is different from "U" only at a lower
layer.  I believe it's this mismatch that's the cause of all
that user confusion.


Larry> but I strongly disagree about the checksum failure message.  It
Larry> indicates a serious confusion about the state of the working file that
Larry> the user *must* investigate.  It indicates that there were local changes
Larry> to the file that CVS doesn't know about and is in the process of
Larry> discarding.  Unless you like losing changes, you must figure out what
Larry> happened to get you into that state and ensure that it doesn't happen
Larry> again in the future.

On Fri, Dec 19, 2003 at 04:45:54PM -0500, Jim.Hyslop wrote:
Jim> Well, there's a couple of problems with that. First of all, the error
Jim> message does not say anything like that - the message is quite terse and
Jim> most users wouldn't know to check their files. Second, by the time the
Jim> operation completes, any trace of the original file is gone, so it's almost
Jim> impossible to investigate exactly what changed - or what CVS _thought_ had
Jim> changed. The original file is not backed up.
Jim>
Jim> So, I think CVS should be modified either to:
Jim> 1) eliminate the "checksum failure" message, or
Jim> 2) modify the error message to make it clearer what happened, and rename the
Jim> original file to .#whatever.

I strongly agree with Jim.  Some more thoughts on how it could be
improved:
  - Saving the user's file as .# backup is the least it should
do.  Better would be to abort the update, leaving the user's
file unchanged.

  - Best of all would be to fall back to a merge instead of to
the current overwrite.  This wins because it reduces the case
to one the user is already familiar with -- saving the .#
file falls out transparently (from the user's point of view;
I don't know about the code's), and the error message can
probably be eliminated after all.

  - Local mode should offer the same level of protection as does
client/server.  (Even though the proximate reason that the
error is detected in client/server (failed patch attempt)
doesn't apply to local mode, the underlying error condition
is just as severe, and just as worthy of action by either the
user or by CVS.)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Checksum failure: serious problem or not?

[Jim.Hyslop]

[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
> Eric Siegerman writes:
> > 
> > The "P" status and the "checksum failure" message should both go
> > away.  (Patched and fully-refetched files should all be labelled
> > "U".)
> 
> I might be convinced about "P" status (although, personally, 
> I like it),
> but I strongly disagree about the checksum failure message.  It
> indicates a serious confusion about the state of the working file that
> the user *must* investigate.  It indicates that there were 
> local changes
> to the file that CVS doesn't know about and is in the process of
> discarding.  Unless you like losing changes, you must figure out what
> happened to get you into that state and ensure that it doesn't happen
> again in the future.
Well, there's a couple of problems with that. First of all, the error
message does not say anything like that - the message is quite terse and
most users wouldn't know to check their files. Second, by the time the
operation completes, any trace of the original file is gone, so it's almost
impossible to investigate exactly what changed - or what CVS _thought_ had
changed. The original file is not backed up.

So, I think CVS should be modified either to:
1) eliminate the "checksum failure" message, or
2) modify the error message to make it clearer what happened, and rename the
original file to .#whatever.

> -Larry Jones
> 
> I think grown-ups just ACT like they know what they're doing. 
> -- Calvin
I second that motion ;=)

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Stable CVS Version 1.11.11 Released! (security update)

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Geoff Beier wrote:

>5. issue the rpmbuild command:
>rpmbuild -ba cvs-1.11.11/cvs.spec
>
>This will place an SRPM in $HOME/rpmbuild/SRPMS and 3 ready-to-install
>RPMs in $HOME/rpmbuild/RPMS/your-architecture.


Actually, They've made it easier than that.  After you set up your
~/.rpmmacros file, and assuming that you don't want to edit your spec
file, just type:

rpmbuild -ta cvs-1.12.5.tar.bz2

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
- --
OPHELIA
  O, what a noble mind is here o'erthrown!
  The courtier's, soldier's, scholar's, eye, tongue, sword,
  Th'expectancy and rose of the fair state,
  The glass of fashion and the mould of form,
  Th'observed of all observers, quite, quite down!
  And I, of ladies most deject and wretched,
  That sucked the honey of his music vows,
  Now see that noble and most sovereign reason
  Like sweet bells jangled, out of time and harsh,
  That unmatched form and feature of blown youth
  Blasted with ecstasy.  O, woe is me
  T'have seen what I have seen, see what I see!

 - Hamlet, Act III, Scene 1, Lines 151-162
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/429rLD1OTBfyMaQRAmoGAJ4zpZXTOt9O8KLAgOkowI5XxNuTZwCg2QxU
fKbAZejC1xZ9LBj1c/xgnsQ=
=87+K
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Stable CVS Version 1.11.11 Released! (security update)

[Tom Copeland]

On Fri, 2003-12-19 at 11:29, Geoff Beier wrote:
> rpmbuild -ba cvs-1.11.11/cvs.spec

Hey, that worked great, thanks for the helpful instructions!

Yours,

tom



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Jim.Hyslop]

Walter, Jan [mailto:[EMAIL PROTECTED] wrote:
> The only reason to put the passwords somewhere else is to 
> prevent someone
> from accidentally checking it out and accidentally changing 
> or deleting
> someone elses' password and checking the file back in.
[...]
> But I think there is a 'gain'
> here by keeping the passwd file somewhere else where some git 
> can't wipe all
> the users by accident and bring development to a grinding halt.
The only people who should have access to the CVSROOT directory are the CVS
admins, so the only gits who have access should be the ones who can most
easily fix the damage. Or am I being hopelessly naive? ;-)

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Checksum failure: serious problem or not?

[Larry Jones]

Eric Siegerman writes:
> 
> The "P" status and the "checksum failure" message should both go
> away.  (Patched and fully-refetched files should all be labelled
> "U".)

I might be convinced about "P" status (although, personally, I like it),
but I strongly disagree about the checksum failure message.  It
indicates a serious confusion about the state of the working file that
the user *must* investigate.  It indicates that there were local changes
to the file that CVS doesn't know about and is in the process of
discarding.  Unless you like losing changes, you must figure out what
happened to get you into that state and ensure that it doesn't happen
again in the future.

-Larry Jones

I think grown-ups just ACT like they know what they're doing. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvspermissions

[Diego Ribeiro de Andrade]

I have been downloaded the suite of scrips 
cvspermissions, but following the install guide I have not got to make it works 
in Red Hat 9. First I have installed Korn Shell to run the scrips... I have 
executed cvspermsetup.sh and it looks to work fine... but when I try to create a 
user it show me a message that Was unabe to commit the changes. Someone use it? 
Someone can show an alternative?
 
Thanks
 
Diego Ribeiro de Andrade
 
Smart Tech Consulting LtdaAv. Rio 
Branco, 181 Grupo 1005Centro - Rio de Janeiro - RJ - CEP 20040-007http://www.smartech.com.brTel/Fax: +55 
(21) 2532-6335Celular: +55 (21) 9759-9638
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Security Issues

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Walter, Jan wrote:

>The only reason to put the passwords somewhere else is to prevent someone
>from accidentally checking it out and accidentally changing or deleting
>someone elses' password and checking the file back in. It's a support
issue,
>not a security one, whether the user intended to change their password or


Actually, the party that requested the change and prompted me to start
this discussion stated a concern for the fact that anyone with write
access to CVSROOT could add passwd to CVSROOT/checkoutlist, `cvs add'
passwd via CVS, then commit it, causing the CVS server to create a
passwd,v that didn't previously exist and overwrite the existing (or
create) CVSROOT/passwd from the archive containing their version of the
passwd file.  Previously to 1.11.11, this could even be used to grant
them root privileges.

Now, the CVS manual does state that permissions on $CVSROOT/CVSROOT
should be controlled as tightly as those of /etc, rendering this point
somewhat moot since if permissions were controlled correctly, then this
wouldn't be able to happen.

It might be reasonable to move the most vulnerable files to a location
where sysadmins are already used to controlling the permissions tightly,
but many other fairly secure applications, Apache and qmail come
instantly to mind, do not seem to find it important to bother with
this.  Anyhow, my reporter was enthusiastic, but I wasn't so sure, so I
thought I would see what others thought about it.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
- --
I will not fake my way through life.
I will not fake my way through life.
I will not fake my way through life...

  - Bart Simpson on chalkboard, _The Simpsons_
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/40QGLD1OTBfyMaQRAtVoAKDU8iOxv8NIphOfMVUbX19n9sIvcgCfXN80
MMNXf147buRrclysvPVFEn4=
=MvXJ
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Win32 builds of 1.12.latest?

[D. J. Hagberg]

Is anybody doing official or unofficial but known-working cvs executables 
for Win32 of the latest rev's of CVS?  The latest I can find on 
cvshome.org is 1.11.9.  That version seems to work OK with the server-side 
1.12.5 but I'd like to keep the versions in synch for my team.

If there isn't an official build, has anyone tried to cross-compile using 
mingw32 on Linux to build cvs executables for win32?

-=- D. J.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Walter, Jan]

Jim, all,

I'll take on a point below:

> -Original Message-
> From: Jim.Hyslop [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 19, 2003 5:19 PM
> To: 'CVS-II Discussion Mailing List'; 'CVS-II Bugs Mailing List'
> Subject: RE: CVS Security Issues

[stuff deleted...]

> > I.e. please do not pretend you can gain anything by 
> pretending to make
> > the CVSROOT/passwd file harder to mess with.
> That's a good point - as Bruce Schneier, author of "Applied 
> Cryptography"
> and a computer security expert, is fond of saying: Security 
> is only as good
> as its weakest link. For pserver, access to the passwd file is not the
> weakest link by any means. Moving the file to a different 
> location will not
> significantly improve its inherent insecurity.
[more stuff deleted ...]

The only reason to put the passwords somewhere else is to prevent someone
from accidentally checking it out and accidentally changing or deleting
someone elses' password and checking the file back in. It's a support issue,
not a security one, whether the user intended to change their password or
someone elses' is another question entirely. But I think there is a 'gain'
here by keeping the passwd file somewhere else where some git can't wipe all
the users by accident and bring development to a grinding halt.

That's my opinion. 

On security, you have two types of security anyways: 1) protection against
malicious people and 2) protection for your data from accidental damage,
deletion, or whatever ("protecting users from themselves"). CVS is part of
category 2, obviously with the support of backup systems and so on. Pserver
figures into category 2 because you prevent the users from accidentally
working in the actual repository and doing stuff like deleting directories.
The keyword here is accidental - either because of ignorance or because one
was not thinking about what directory someone happened to be in. I would
also argue category 2 is (still) responsible for most data loss in the world
today.

Your opinion?

Seasons greetings,

Mr. Jan Walter
Chief Architect

DEFINIENS AG
Trappentreustr. 1; D-80339 München
Phone: +49-(0)89-231180-18
Fax: +49-(0)89-231180-90 
[EMAIL PROTECTED]
http://www.definiens.com



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Stable CVS Version 1.11.11 Released! (security update)

[Geoff Beier]

On Fri, Dec 19, 2003 at 10:48:47AM -0500, Tom Copeland wrote:
> Just wondering if you've had a chance to put together the source RPMs
> yet...

While you're waiting, it's easy to make your own from the source
tarball, since the tarball includes an RPM specification.

1. If you've never constructed an RPM before, you should first 
create a file called .rpmmacros, which contains a directive 
setting your topdir to a directory your non-privileged account 
can write to:

echo "%_topdir $HOME/rpmbuild" >$HOME/.rpmmacros

2. Create the directory structure needed for RPMS:
(assuming you're in your home directory and used the _topdir above)

mkdir -p rpmbuild/BUILD  rpmbuild/RPMS  rpmbuild/SOURCES rpmbuild/SPECS  rpmbuild/SRPMS

3. Extract the source tarball in your home directory (or at least extract
cvs.spec)

4. Copy the (compressed) source tarball into rpmbuild/SOURCES

5. issue the rpmbuild command:
rpmbuild -ba cvs-1.11.11/cvs.spec

This will place an SRPM in $HOME/rpmbuild/SRPMS and 3 ready-to-install
RPMs in $HOME/rpmbuild/RPMS/your-architecture.

HTH,

Geoff


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Security Issues

[Jim.Hyslop]

Greg A. Woods [mailto:[EMAIL PROTECTED] wrote:
> It would be much Much MUCH better to begin to deprecate any and all
> support for "cvs" passwords than to give any further support to the
> false illusion of any security someone might pretend to see in them.
> 
> CVS pserver support is, just barely, safely usable _only_ for truly
> anonymous access (which normally also means read-only access) 
> (and only
> then when there's some underlying network integrity protection),
> regardless of how your network works, which clients you use, etc.
> 
> _ANYONE_ considering the use of some tool like CVS obviously 
> also needs
> at least some degree of true security (i.e. authentication,
> accountability, _and_ integrity) -- otherwise they're doing worse than
> fooling themselves (they're fooling _everyone_ involved with 
> using their
> repository).
OK, I'm going to play dumb here (please, no accusations of "playing" :-).
Why is this level of security so important? Exactly what are the security
attacks you're concerned with?

Well, clearly pserver is not secure because the password is sent effectively
in plain text, allowing anyone with a packet sniffer to retrieve CVS
passwords. That's a big no-no on the security level. But this is
well-documented in the Cederqvist - as I recall, it says something along the
lines of "if you want real security, don't use pserver."

Let's look at where pserver will probably be used. It will not (if the CVS
admins have any sense) be used on repositories that are accessible from
"outsiders" (the Big Bad Internet, for example). Network access to the
server will be restricted. This divides the attackers into two categories:
the insiders and the outsiders. We can pretty much discount the outsiders -
they'll have to hack through firewalls, etc. to get in, and are more likely
to find other servers much more interesting than CVS. Unless you think that
I'm underestimating the mindset of corporate raiders, who might actually do
this kind of hacking to get at a competitor's intellectual property.

For the insiders, again there's a limit to how much the attacker can do.
Most users only want to know enough to run the basic checkin/checkout
commands. Unless they have direct access to the repository, there is very
little damage they can do that cannot be fairly easily undone. For the
knowledgeable user who knows how to inflict real damage on the repository,
*and* who has the desire to inflict such damage, moving to a more secure
protocol like kerberos will probably slow them down, but will not, in the
end, stop them from harming the repository. To paraphrase the well-known
saying, pserver is there to keep honest people honest.

I can envision a wide range of theoretical attacks that someone _could_ do.
But who would actually _do_ those attacks?

So, where am I deluding myself?

> I.e. please do not pretend you can gain anything by pretending to make
> the CVSROOT/passwd file harder to mess with.
That's a good point - as Bruce Schneier, author of "Applied Cryptography"
and a computer security expert, is fond of saying: Security is only as good
as its weakest link. For pserver, access to the passwd file is not the
weakest link by any means. Moving the file to a different location will not
significantly improve its inherent insecurity.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Stable CVS Version 1.11.11 Released! (security update)

[Tom Copeland]

Hi Derek -

Just wondering if you've had a chance to put together the source RPMs
yet...

Thanks,

Tom

On Thu, 2003-12-18 at 16:48, Derek Robert Price wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Stable CVS 1.11.11 has been released.  Stable releases contain only bug
> fixes from previous versions of CVS.  This release adds code to the CVS
> server to prevent it from continuing as root after a user login, as an
> extra failsafe against a compromise of the CVSROOT/passwd file.
> Previously, any user with the ability to write the CVSROOT/passwd file
> could execute arbitrary code as the root user on systems with CVS
> pserver access enabled.  We recommend this upgrade for all CVS servers!
> 
> Take a look at the NEWS file
> <
> from the source distribution or go directly to the downloads page
> .
> 
> 
> MD5 Sum:
> 
> e2ceb57c06dc532d0156bdba687073c9  cvs-1.11.11.tar.bz2
> 
> Derek
> Public key availble from 
> Public key fingerprint: CB6A 07CA 90C5 4234 E8A3 C8D0 2C3D 4E4C 17F2 31A4.
> 
> - --
> *8^)
> 
> Email: [EMAIL PROTECTED]
> 
> Get CVS support at !
> - --
> There are three kinds of men. The ones that learn by reading and the
> few who learn by observation. The rest of them have to pee on the
> electric fence.
> 
> - Will Rogers
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
> 
> iD8DBQE/4iC9LD1OTBfyMaQRAkH+AJ4hoR6y3oAtgEqqxxpFI1Gd2hARFwCg9W1a
> ii041122dO3/UlGe4oKy988=
> =Joxc
> -END PGP SIGNATURE-
> 
> 
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
-- 
Tom Copeland <[EMAIL PROTECTED]>
InfoEther



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Checksum failure: serious problem or not?

[Jim.Hyslop]

Eric Siegerman [mailto:[EMAIL PROTECTED] wrote:
> Personally, I'd be in favour of CVS hiding the distinction
> between "patch" and "update".  They both lead to the same end
> state, and which method CVS chooses is an implementation detail
> that's irrelevent to end users.
> 
> The "P" status and the "checksum failure" message should both go
> away.  (Patched and fully-refetched files should all be labelled
> "U".)  I can understand wanting to distinguish the different
> cases while debugging, but that's what "#ifdef DEBUG" is for...
I certainly agree about the "checksum failure" message - it can cause
consternation among users. I'm not so sure I agree about hiding the
distinction, though. Is there any use-case in which the user would really
need to know? For example, concern over bandwidth - if the user sees 'U',
then they may choose to use the -z global option for compression, which they
may not otherwise use. Am I stretching things, maybe?

You could always submit a patch, and see if anyone notices that 'P' never
shows up any more ;=)

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs