This looks like a serious security problem. It appears to open
anonymous CVS servers to a wide range of attack.
Ian
--- Start of forwarded message ---
To: [EMAIL PROTECTED]
Date: Fri, 28 Jul 2000 17:21:28 +0900
From: Tanaka Akira [EMAIL PROTECTED]
Subject: cvs security
From: Karl Fogel [EMAIL PROTECTED]
Date: 28 Jul 2000 14:01:23 -0500
Ian Lance Taylor [EMAIL PROTECTED] writes:
This looks like a serious security problem. It appears to open
anonymous CVS servers to a wide range of attack.
It looks serious, but not for anonymous-only
Date: Fri, 28 Jul 2000 17:45:13 -0400 (EDT)
From: [EMAIL PROTECTED] (Larry Jones)
Ian Lance Taylor writes:
What if I frob Update.prog? I don't claim to understand all the cases
here, but it appears that that will be run by `cvs update'.
Update.prog just contains the name
Date: Fri, 28 Jul 2000 17:36:53 -0400 (EDT)
From: Pavel Roskin [EMAIL PROTECTED]
I hope that there is no immediate danger. Look at serve_update_prog() - it
checks whether commits are allowed and exits if they are not. It prints a
strange message though:
E Flag -u in modules
Date: 28 Jul 2000 14:58:08 -0700
From: Ian Lance Taylor [EMAIL PROTECTED]
Date: Fri, 28 Jul 2000 17:36:53 -0400 (EDT)
From: Pavel Roskin [EMAIL PROTECTED]
I hope that there is no immediate danger. Look at serve_update_prog() - it
checks whether commits are allowed
Derek R. Price [EMAIL PROTECTED] writes:
It was already trying. I just checked in a temporary fix, but the real
problem is that CVS's GSSAPI code is written wrong. It shouldn't
require krb5 headers at all.
I wrote it that way to take advantage of Kerberos's mapping between
GSSAPI user
Derek R. Price [EMAIL PROTECTED] writes:
Vesa Suontama wrote:
What are the conditions, that make a file unpatchabe at the first update
pass?
I don't know. That's why I asked you.
A typical case is that the file is somehow modified after the CVS
process starts, so the application of
Russ Cox [EMAIL PROTECTED] writes:
Specifically, the CVS client never hangs up.
The problem is in the client, since
I'm using well known servers like :pserver:[EMAIL PROTECTED]:/vger,
a repository for the Linux kernel source.
I believe the problem is in get_responses_and_close,
[EMAIL PROTECTED] (Larry Jones) writes:
SCCS can retrieve any revision in one pass through the file. As you
say, there are the equivalent of #ifdefs that specify which revisions
include the following lines , so there's very little processing time,
it's mostly just I/O time. CVS as
[EMAIL PROTECTED] (Larry Jones) writes:
Ian Lance Taylor writes:
It was not the case formerly that CVS read the entire RCS file to
retrieve the head revision. I haven't looked at the current code.
But previously CVS would just read the RCS header (including all the
tags
Stefan Monnier [EMAIL PROTECTED] writes:
Over the last few years, I've had several times people complain about
PCL-CVS' diff output being incorrect (with parts missing).
Now my direct `read' calls from GDB make me believe that maybe the
problem is not in Emacs, but in CVS instead (I use
Stefan Monnier [EMAIL PROTECTED] writes:
Another notable thing is that this whole problem disappears if I
change PCL-CVS to use a pty rather than a pipe for the process' output.
(I noticed it because the problem doesn't appear with VC which is
not careful to use a pipe).
Now my direct
kevin wang [EMAIL PROTECTED] writes:
The problem is that in a standard configuration:
--stderr- -stderr
/ \ / / \
CVS ServersshCVS clienttty
\
kevin wang [EMAIL PROTECTED] writes:
From Richard Stallman
If a buffer flush fails with EAGAIN during
printf, what should happen?
printf should retry, perhaps after a short sleep, and thus more or
less emulate the behavior with an ordinary blocking descriptor.
If you
Richard Stallman [EMAIL PROTECTED] writes:
The problem is that people use cvs 21 with CVS_RSH set to ssh, and
expect it to work, and think it is a CVS bug when it fails. Educated
users don't have a problem.
Does educated users mean users who know they have to avoid 21
when
15 matches
Mail list logo
