[Zope-dev] FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)

[Steve Spicklemire]

Hi Shane,

   This is great.. it does what I wanted to do, but by making a 
'fixed name' folder, (a la, 'acl_users'), to do the trick. It also
works a lot more like a 'real' CVS folder. Cool. And.. icing on the
cake... you can put it in any kinda container! Double Cool!

>>>>> "Shane" == Shane Hathaway <shane@digicool.com> writes:

    Shane> It looks good, but the interface could be a lot cleaner.  I
    Shane> envision a table with three distinct column groups: the
    Shane> ZODB version, the FS version, and the repository (with
    Shane> details).

Yes.. that sounds good. In my dreams we'd do away with the FS part
altogether.. but I think that's another project in itself!

    Shane> When the ZODB and FS are in sync, a small black equal sign
    Shane> will appear between them (preferrably a graphic to make it
    Shane> more visible.)  When the FS and repository are in sync,
    Shane> there will be a small equal sign between them also.  When
    Shane> something is not in sync, a green arrow pointing in the
    Shane> direction the file needs to go will replace the equal sign.

Yes... unfortunately it's possibly, easy really, to get them out 
of sync in both direction... some kinda scary "AHHH!!!" graphic
needed for that case mayhaps.. 

    Shane> The buttons below would be placed in such a way to make
    Shane> their function obvious.  In fact, the submit buttons could
    Shane> be images containing the arrow icon.  Thus the interface
    Shane> would be simple and obvious.

Cool.. yes I like that.

    >> I've also found it useful for managing Python products and
    >> other software through the web! I have had a couple of minor
    >> 'breakthrough's that *seem* cool, but I might just be fooling
    >> myself. If an object is not folderish I guess that it's
    >> 'simple' so I export it as XML with the following code:
    >> 
    >> (snip)

    Shane> This looks good, Steve.

    >> If objects are 'folderish' or 'complex' (and the user is
    >> permitted to dictate this when objects are added to CVS), they
    >> are exported as 'zexp' files and cvs adds them as 'binary'. I
    >> was having trouble with certain kinds of object's xml
    >> representation.  I decided that this was really an xml
    >> implementation problem, since I couldn't reliably export these
    >> as xml through the normal Zope export mechanism
    >> either. Anyway..  let me know what you think if you are using
    >> this stuff!

    Shane> I think we need to look into performing complete CVS
    Shane> checkouts which create entire folder hierarchies.

Yes... with the new 'CVS' folder concept we could try the 
following heuristic...

If you run into a 'folderish' object during checkin, or checkout,
see if it contains an object named 'CVS', if so.. recursively
call the same method on that object, if not, treat it as
a 'chunk' object in its own right.... ..... ??? Would that work?

    >> Finally I'm aware that there are also security issues with the
    >> way this works now. I need to look at all the things a user
    >> might need to do and eliminate some of the 'type in' arguments
    >> that are in the product now. These arguments wind up on
    >> 'os.system' calls, and could be abused by a ill-meaning user
    >> (with access to the CVS Admin page!)  Any thoughts there?

    Shane> Imagine this possibility: Zope would start what I'll
    Shane> tentatively call an "execution proxy" server at startup.
    Shane> When a user want to access CVS through Zope, they would be
    Shane> required to start a background "execution client" which
    Shane> makes a connection to Zope's execution proxy server.  When
    Shane> the user accesses a CVS function in Zope, Zope would look
    Shane> at the list of connected execution clients and ask the
    Shane> appropriate execution client to access the file system and
    Shane> execute cvs commands based on that user's system
    Shane> privileges.

    Shane> Advantages:

    Shane> - Unless a given user is running the execution client, the
    Shane> possibility of intruders gaining access to that user's
    Shane> files is not increased.

    Shane> - Nothing has to run with root privileges.

    Shane> - The execution proxy could run on a privileged port,
    Shane> making it impossible for intruders to trick users into
    Shane> using a counterfeit execution proxy (unless, of course, the
    Shane> intruder already has root privileges.)

    Shane> - No need for administrators to fiddle with filesystem
    Shane> permissions.

    Shane> Disadvantages:

    Shane> - If Zope is compromised while execution clients are
    Shane> connected, the intruder may be able to execute commands
    Shane> through the execution clients.  To reduce the impact, we
    Shane> can reduce the commands allowed to be executed.  Note,
    Shane> however, that this problem is very likely inherent in CVS
    Shane> access through the web.  Even the current implementation
    Shane> suffers from this problem.

    Shane> - Users will have to manually start their execution
    Shane> clients, which will stop automatically when they log out.
    Shane> This is actually designed to be an advantage in terms of
    Shane> security.  On the other hand, it would be possible to write
    Shane> an execution client that runs as root and automatically
    Shane> spawns child clients for each user.  That could be
    Shane> dangerous, though.

    Shane> It should be relatively easy to write all this IMHO.

Hmmm ... I think it might stretch my time/energy barriers! ;-)
But I'd love to *help* write it.

    Shane> Shane

So.. I'd like to add you as a 'commit'er to my local CVS... 
are you intersted?

thanks!
-steve