Comment 13 for bug 710410

Aha -- I see people have already made the suggestions below. (I'm using
gmail and it started a fresh thread due to the new subject. ;-) The only
ones that remain are a) perhaps ask the user if they intended that message,
and b) if it's also in the repository, might need to deal w/ it there, at
least to prevent it from being brought back into branch.conf as
un-escaped/un-encoded/not-stored-as-file text by an uncommit.

-- Pat

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.
>