* HACKING   (String operations): Justify string security concerns better.   (Document everything): Remove comment about documenting security   boundaries.
* HACKING
  (String operations): Justify string security concerns better.
  (Document everything): Remove comment about documenting security
  boundaries.

There is not a single interface currently in Subversion that adheres
to the recommendation about documenting security boundaries.  None.
Zip.  Nada.  In fact, no source or header file contains the word
"security" at all, in either lower- or upper-case.  Hello? :-)

If we want to document such boundaries this way, fine, we should start
doing so.  But recommending a *completely* unused practice in HACKING
is counterproductive and insincere.  A reader looks at HACKING, looks
at the code, sees that there's no connection, and the result is that
the HACKING guidelines lose a degree of credibility (and they
currently have a lot of credibility, precisely because what they
recommend is, by and large, actually practiced in the code).

We don't need to wait for "perfection" here, but nor should we indulge
in total wishful thinking in the HACKING file.  Let's see some
real-life examples of security boundaries, and document them.  Then
we'll be able to write something about it in HACKING without
hypocrisy, using examples and recommendations that are specific to
Subversion instead of being generic guidelines never tested in this
particular project.



git-svn-id: f8a4e5e023278da1e04e203c7fe051e3c4285d88@841827 13f79535-47bb-0310-9956-ffa450edef68

wbond/subversion,wbond/subversion,wbond/subversion,YueLinHo/Subversion,wbond/subversion,YueLinHo/Subversion,wbond/subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,wbond/subversion,wbond/subversion,YueLinHo/Subversion,YueLinHo/Subversion