Ben Collins-Sussman wrote on Mon, 5 May 2008 at 15:00 -0500:
> Last week, a googlecode user manually modified some svn:date revprops
> on his repository. He got the format incorrect, but wasn't aware.
> However, things started breaking as a result. Our viewvc-like source
> browsing choked on the invalid svn:date format (which we're fixing),
> but even plain old 'svn log' produced 'invalid date' errors, rendering
> the command useless.
>
> I'm wondering if it doesn't make sense to have libsvn_repos (or fs?)
> do some simple server-side validity checks on incoming svn:date
> values, and reject the revpropset if they fail. We already do
> validity checks on filenames and log messages ("no control chars
> allowed"), and validity checks on things like 'svn:eol-style' . After
> all, subversion controls the values of svn:* props, we have the right
> to refuse bad values.
>
Attached patch to implement libsvn_repos validation at propset time. (It
does not address "svn log"'s errors when the latter fails to parse
malformed svn:date properties.)
[[[
Validate svn:date property values in libsvn_repos.
Suggested by: sussman
* subversion/libsvn_repos/fs-wrap.c
(svn_time.h): Include.
(validate_prop): Add optional 'value' and 'pool' parameters. Extend to
validate the value for svn:* properties.
(svn_repos_fs_change_node_prop, svn_repos_fs_change_txn_props,
svn_repos_fs_change_rev_prop3):
Pass pool and property value to validate_prop().
* subversion/tests/cmdline/prop_tests.py
(invalid_propvalues): New test.
(test_list): Run new test.
]]]
---------------------------------------------------------------------
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-10 15:05:28 CEST