Re: 'checkoutinfo' trigger?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim.Hyslop <address@hidden> writes:

> For us, an equivalent to the 'commitinfo' which
> runs at checkout-time would be very useful. The
> trigger would behave the same - an exit code of
> 0 allows the checkout to proceed, and a non-zero
> exit code aborts the checkout. Are we unique in
> this requirement, or are there other people on
> this list who would find a checkout trigger
> useful?

I have seen something like your requirement, but
is was inverted.

That is, I have seen some code that needed to be
moved to a separate repository which had more
restricted logins so that only a subset of users
could access it due to contractual obligations
between two companies to work on a common
subsystem.

In the case I have seen, it was felt that the
separate repository was a requirement to avoid any
possibility for holes in the source control system
to be used to let unauthorized users into the
system. It was also the case that strict controls
were placed on where such restricted software
could be checked out, so that no one could just
NFS mount a checked out copy of the software and
use it. In fact, software that did backups had to
be done separately for such joint projects as well
due to the fear of the company owning the IP that
the joint development IP might be misused.

This differers from your case where only a portion
of the repository is restricted.

I would think that the solution to your problem
would be that the commit triggers for your new
co-op code would open the umask for newly added
directories and files to be 000 to allow anyone
access to those files.

If you do feel some kind of trigger on checkout
is needed, you will need to consider:

  How does the new policy interact with the
  following add-ons?

      - CVS Monitor
      - CVSGraph
      - CVSPlot
      - CVSconnect
      - CVSsuck
      - CVSup
      - CVSweb
      - ViewCVS

  Is is possible for a non-authorized user to
  just go and look at someone else's checked out
  tree?

  Is it possible for a non-authorized user to
  go to backups of a tree and read those?

If there is value to your proposed enhancement,
you will probably also need to include some
documentation that at least discusses the inherent
dangers of assuming that the sources are 'secure'
just because the cvs admin enables this proposed
feature.

I have no fundamental problems with adding a
checkout trigger. It suppose it might let cvs
administrators 'hide' things in CVSROOT more
effectively if there is a need to do that.

        Thanks,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCHLzg3x41pRYZE/gRArYrAJ97FuPuEVj/kKqP3mcoaEgnwdyJ+ACfSSly
qYxHENjTuHbrOl13NslWikM=
=PvfD
-----END PGP SIGNATURE-----