[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: denial-of-service attack prohibits all users from creating new repos
Mark D. Baushke
Re: denial-of-service attack prohibits all users from creating new repositories
Tue, 01 Jun 2010 13:16:23 -0700
Bruno Haible <address@hidden> wrote:
> But your security feature can too easily be circumvented: A user can
> do "cvs init" on another machine and then copy the resulting CVSROOT
> directory to the place where he wants to have it. Like this:
> $ cvs -d `pwd`/new init
> $ (cd new && tar cf - CVSROOT) | (ssh other-machine tar xf -)
Yes. I agree.
The assumption has been that the local repository would also be 'locked
down' which is why I said that this 'feature' is more for the set-uid
and/or set-gid cvs executables than the vanilla executables.
It is also the case that accidents happened and the 'error' was put in
place to 'help' folks who kept stepping on themselves.
> Before I put in this workaround into 'autopoint', can you please tell me:
> 1) Under which copyright are these files CVSROOT/* created by 'cvs init'?
> Are they public domain, or copyrighted? by whom?
The default files added to the repository as seen as examples provided
by CVS... they are basically comment blocks in files. They have existed
inside of the CVS mkmodules.c file for a very long time. I guess I would
suggest that they are under the GPLv1+ license, but I would not fight
hard if someone wanted them to be in the public domain.
> 2) Do you intend to fill the hole in the security feature that I pointed
> out above? That is, to disallow the workaround in some way?
No. I was not a big fan of the implementation as it was made in the
first place. I related the rationale (possibly read as rationalization),
not what I think about it.
> 3) Is there compatibility with the CVSROOT/* files between different
> versions of cvs? That is, will the infrastructure files from cvs 1.11
> work with cvs 1.12.14, and vice versa?
cvs 1.11.x files are able to be completely be used by cvs 1.12.x without
problems (well, some warnings will be made).
cvs 1.12.x files may not be well understood by cvs 1.11.x, but the
latter is supposed to ignore things it does not understand.
> If I cannot use this workaround, I'll have to deprecate the configuration
> option --with-cvs of GNU gettext, and enable --with-git by default instead.
Given that I have been getting no response from Derek on the timing for
the next release of cvs 1.12.x or later, I suggest that --with-git is a
better alternative default.
fwiw: I am not happy that CVS appears to be stalled right now... Sigh.
I regret being the bearer of this news.