Hi all,
Before I go into any background, details and my own ideas about this, my
basic question is:
Is it possible to refuse commits to a subversion repository based on the
content of files that are being committed? And if so, how?
The reason I'm asking is that I'd like to implement virus scanning to
prevent infected files from ending up in a repository.
Background:
===========
I am setting up a subversion server that will be used to maintain a
number of web sites. The general idea is that webeditors will be given
access to a repository and upon every successful commit a trigger will
be sent to the web server. That in turn will perform an update (using a
read-only user). I think this kind of set up has been discussed before
on this list.
Although all of us always use the latest virus scanning software on our
machines, right?, it may just be possible that a web editor
accidentically commits a binary file, e.g. .jpg, .wav etc. that contains
a virus. I would try to avoid subjecting unsuspecting visitors of the
corresponding web site to those files..
OS + Subversion version:
=========================
I am running:
- RHEL 4
- apache 2.0.x + svn 1.2.3 (using https, ldap auth and mod_svn_authz)
I am considering clam-av for the actual virus scanning though there are
other linux virus scanners out there of course.
My initial idea about solving this:
===================================
My first idea was to write a pre-commit script, that:
- passes the new files to a virus scanner
- fails (exit 1) if any of them contain a virus; preferably giving the
user a warning.
But from what I have found so far is that during a pre-commit I can get
access to all meta-data (author, log message, filenames, etc), but not
the actual files themselves. Does anybody know:
a) whether this can actually be done
b) of another way to prevent commits of files containing a virus
I have also considered work arounds for this problem. E.g. post commit
checking on the server, and in case of trouble take action (roll back or
something). Or using branches. But of all of this complicates matters,
at least from an administration and end-user point of view, so I'd
rather go for the prevent-it-all solution if it can be done.
Cheers for any help,
Tim Bruijnzeels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 18 13:47:43 2006