Re: Public Nmap SVN Repository

[William McVey <wam () cisco com>]

On Thu, 2006-12-14 at 02:20 -0800, Fyodor wrote:
> * A mailing list (nmap-commits or something) will be set up, to which
>   commit notifications (with diffs inline) will be sent, through a
>   post-commit hook.

You want to be careful about flooding out too much information such that
subscribers end up not reading it. I've generally taken the approach
that people are interested in 'what' changed, not how. So sending out
just the log notes (and demanding contributors to use good commit log
messages). If people want to know how a particular change was
implemented, they can always do a 'svn diff'.  I also generally will
queue up my set of changes and just mail out one daily email of the svn
logs for that day, if there are any (launched from cron). Of course,
that's just how I do my notifications. If you prefer to do per-update
email with diffs, check out tools/hook-scripts/mailer/ form the
subversion source.

I'll also jump on the RSS bandwagon; although I certainly don't think it
is a complete replacement for mail. RSS would allow people who keep up
to date on a day to day basis up to date. Mail is good in that it can
queue in an filtered folder and get reviewed on a much less periodic
basis. As an FYI, there is an svn to rss filter in
contrib/hook-scripts/svn2rss.py of the subversion distribution.

> While those are my current plans, I have a few questions for you guys:
>
> Does anyone know any good reasons for using mod_dav_svn (Apache)
> rather than my current plan of svnserve?

It's my understanding that using mod_dav_svn is better if you want to
leverage other capabilities of Apache or its modules. For example, if
you want subversion to use SSL for transactions then it's much easier
using the mod_dav_svn combined with mod_ssl. I don't have a lot of
experience with svnserve, but I believe they do avoid sending clear text
passwords over the wire (at the expense of clear text pws, not just
hashes, stored on the server side); however, the integrity of the actual
data being uploaded isn't protected at all with svnserve. Other apache
modules are somewhat useful in the context of a source code repository
as well (mod_deflate, mod_auth_ldap, mod_*_cache). It depends on how
high you want to scale.

Personally, I use the mod_dav_svn module and don't have much problem
with it. I was already running Apache. Subversion (even svnserve) is
built using the Apache libraries (APR), so I don't see mod_dav_svn as
any more/less likely to be "buggy" than the standalone daemon. I also
prefer having SSL protection of my authentication creds. My biggest
complaint is that the fine grained authorization mechanism for the web
module (authz) is somewhat cumbersome, although I believe it is still
better than the hook-based access control available through svnserve.

> A quick search finds this script for sending commit emails:
> http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/commit-email.pl.in
> Can you guys recommend this, or do you know anything better?

In that same hierarchy there are scripts in perl, ruby and python (in
the mailer subdir). It's all a matter of preference. The script I use
for daily log notifications is at:

https://svn.wamber.net/projects/wamber/browser/wam-homedir/trunk/bin/report-svn-changes

it depends on svn-gnuify-changelog (part of the subversion package under
tools/dev). The script also has a bug in that 'svn log' ranges don't
quite behave the way you might expect, which yields duplicated change
notifications if no changes occur for an interval.

> How important do you guys think it is to be able to browse the
> repository with a web browser, link to revisions, etc. using something
> like ViewCVS or Trac?  I don't presently plan to implement this, but I
> probably can if there is demand.  If you want it, what software do you
> recommend?

I really like Trac. Both for it's repository viewer, as well as for the
integrated Bug tracking system, Wiki and extensive RSS support. Trac has
RSS feeds for just about everything.. from new repository transactions,
submitted bugs, particular bug updates, new pages on the wiki, new
content on a particular page of the wiki, etc). That being said, it does
have quite a few "moving parts" that could hide vulnerabilities.

> Is there anything else you think is important to consider for a new
> Nmap public source repository?

I highly suggest going with the FSFS backend storage option for the
repository. I had some issues with the berk-db backend. Also, with the
FSFS backend, the file permissions of the db files make more sense. With
the Berk-DB option, I believe you had to set the write bit even for
read-only access.

  -- William

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org