bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preventing mistakenly deleting branch tags


From: Derek R. Price
Subject: Re: Preventing mistakenly deleting branch tags
Date: Mon, 04 Jun 2001 15:41:24 -0400

Stephen Cameron wrote:

> his mistake:
> cvs tag -d sometag
> "Oh crap, I meant to type someothertag!  sometag is my branch tag!!! ^C^C^C^C"

Steve, I'm behind you on this.  If I don't hear objections from the other
developers, it works with -F too, it comes with docs & sanity, and it works
(period), I'll check it in.


> Your proposal does not address this problem at all, yet it is an instance of
> the main problem which I am trying to address.  We have two different goals:
> My goal: prevent _accidental_ move/delete of branch tags.  Your goal: prevent
> _intentional_ move/delete of (any?) tags, and more generally, restrict various
> random CVS commands to various random users at administrator's discretion.
>
> These two goals are independent.  You could have either, both, or neither.
> >
> > Having the ability to restrict cvs commands to certain users is
> > maintainable and provides a much better security blanket.
>
> and it solves a different problem than I'm trying to solve.

And it does seem that when the users have to resort to the sysadmin or the 
manual
to figure out '-b', a big glaring "DON'T DO THIS
UNLESS YOU'RE REALLY SURE YOU KNOW WHAT YOU'RE DOING!!!  IF YOU'RE NOT THE CVS 
ADMINISTRATOR,
ASK HER FOR HELP!!!", should do the trick.

As for the rest of it, there's a developer here at CollabNet who wrote an
XML security interface for CVS.  Basically CVS starts up or contacts a remote
security server, tells it what it's doing and who's doing it, then allows the
remote bit to abort at any time.  This has the advantage of moving the *info
hooks, and thus most of the logging and security, into a single module outside 
of
CVS as well.  If portable SH and C or Perl modules were written to go along with
this that mimic the standard *info behavior, it could be usable (read, backwards
compatible).

This code still crashes too often and there are no *info mimics yet, but I think
there's a lot of potential here.  It would effectively solve several problems
regarding extensibility and issues such as command line arg limits which I and
others have worked on, as well.  If anyone wants to help, I could probably get
the code away from the CollabNet developer or put it somewhere mutually
accessible for collaboration.

Anybody have comments on this design, BTW?

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@collab.net         CollabNet ( http://collab.net )
--
I cannot live without books.

                        - Thomas Jefferson






reply via email to

[Prev in Thread] Current Thread [Next in Thread]