On 08/19/2008 05:19 PM, Jon Jensen wrote:
> Interchange users,
>> At the talk "Rails Security" by Jonathan Weiss at LinuxTag 2008, he
> mentioned (among other things) a possible security problem for sites being
> run out of a Subversion (or CVS) working copy, where the metadata inside
> the .svn/ or CVS/ directories may be exposed to the world.
>> This post by someone else explains it nicely:
>>http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/>> Interchange appears not to be vulnerable to this by default as it will
> only serve files that end in .html, and all the .svn/ and CVS/ filenames
> have no suffix, or end with .svn-base, so are not served by Interchange.
>> But if the docroot is served from a Subversion or CVS checkout, its
> metadata files are likely served to the world -- relatively harmless, but
> can reveal internal file paths, hostnames, and OS account names.
>> For PHP or SSI, on the other hand, this could be a disaster, as the
> complete source to all files could be revealed, since the .svn-base suffix
> will cause Apache not to parse the code as PHP but pass through the
> source.
>> If you use Subversion or CVS on any project, I recommend you look into how
> your files are being served and see if there's anything being exposed.
> Checkouts from Git, Mercurial, or Bazaar are not likely to be a problem,
> since they only have metadata directories (.git, .hg, .bzr) and associated
> files at the root of the checkout, which would often be outside the
> docroot.
Just a side note, that this is bad practice anyways. You should
maintain your CVS, SVN, GIT, etc repositories separately from your
running copy of IC. It is a good idea to use the standard, perl
Makefile.PL, make, make test, make install method to install your
running copy of IC (as well as other programs) as this method does not
copy the CVS, SVN, etc directories anyways, plus it checks certain
system dependencies and sets variables, etc.
Peter