Greg Hudson wrote:
> * This is a simple wrapper program, but it has been coded as a
> capital-p-Project. It has five source files and 1939 lines of code
> (mostly comments), separate src/ and include/ directories, and man pages
> for the internal functions contained within. The ratio of overhead to
> actual functionality is off the chart, especially for a program which
> ought to be easy to audit (since it runs with elevated privileges).
True, there is a lot of non-code. I would expect that to be a welcome
thing; most people complain about the *lack* of documentation. I
figured that the extensive documentation would make it easier to audit,
not harder.
sloccount gives me 846 lines of code, and 300+ of that is for some
aggressive safety checks to help ensure the user can't exec() an
arbitrary executable and gain privileges. (Note that the wrapper should
NOT be installed setuid/setgid root -- there should be an unprivileged
user/group specifically created for accessing the repository. This way,
if a user does find a vulnerability in svnstsw or svnserve, the user
would gain full read/write access to the repository and nothing else.)
> It would be disappointing to
> see stuff added to the project's main autoconf grot in order to support
> a contrib program.
I expect most developers feel this way, but I'm not sure so I thought
I'd ask. Most of the autoconf stuff currently in svnstsw can be left
out without major loss of functionality, with C99 being the exception.
It would make my life easier if I could test for C99; if the community
has substantial reservations about it, I'll have to move to plan B.
> Maybe the C99 check breaks on some people's machines
> and they can't build Subversion, even though Subversion proper depends
> only on C89.
The C99 autoconf test sets the shell variable ac_cv_prog_cc_c99 to 'no'
if a C99 compiler is not found -- it does not fail out. If the user
does not have a C99 compiler, we could use this variable to simply skip
building svnstsw.
If conditional compilation is not possible with Subversion's current
build system, or if testing for C99 functionality is out of the
question, my options are: (1) remove svnstsw entirely, (2) add the
ability to conditionally compile code to Subversion's build system, (3)
re-write svnstsw without using C99 features, or (4) leave everything how
it is right now.
It would be sad to choose option #1 since I think that this code is
useful to some people. I'm reluctant to pursue option #2 for just a
contrib program since it would be a major change to the build system.
Option #3 would take time, and would require introducing malloc() into
the code. Option #4 is easiest, but it makes life harder for
users/package maintainers, plus developers have already expressed
discomfort with this option.
There is another option: add the equivalent functionality to svnserve
directly. There would be some backwards-compatibility concerns, however.
-Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-05 23:23:38 CEST