Comment 12 for bug 710410

> So, the problem in the underlying ConfigObj: it can write bad conf file and
> unable to read it back.
> I'm not quite understand how to fix it in the QBzr.
>
>

> ** Summary changed:
>
> + ConfigObj is able to write bad branch.conf which is not possible to read
> back
>

bzr could get any sort of file thrown at it via -F, including ones that have
text that looks like meaningful strings in branch.conf, or binary data,
or...is there an equivalent of cross-site-scripting when reading branch.conf
(not likely, if it doesn't direct bzr to take actions, but just as an
example...).

Some options to protect against that:

1) Check whether it appears to be a reasonable text message, e.g.: Do a
trial run at running it through the parser *as it's being read in* and see
if it will cause trouble. Do whatever check is appropriate on the system
for binary vs. text. Scan it for bzr keywords. Ask the user if they really
want that message.

2) Quarantine messages, or at least ones that seem iffy: Escape the text or
run a simple encoding-to-text on it. Store it as a separate file (at a
known relative path w/i .bzr/branch) and only put the filename in
branch.conf. This would apply not just to the message stored in
branch.conf, but wherever else it is stored in the collection of revisions.

To recover your affected tree you just need delete [commit_data] section and
> all its contents from branch.conf.
>

;-) Getting it back from launchpad worked. But that brings up another
point (alluded to above), which is... Isn't that message stored in some
other place as well, in repository directory itself? It doesn't appear to
have caused problems for commands that access the repository, but if stored
there, it could resurface via uncommits.

-- Pat