Nathan Hartman wrote on Wed, Jan 18, 2023 at 01:10:47 -0500: > On Tue, Jan 17, 2023 at 3:02 PM Doug Robinson <doug.robin...@wandisco.com> > wrote: > > > Daniel, et. al.: > > > > On Mon, Jan 2, 2023 at 5:14 PM Daniel Sahlberg < > > daniel.l.sahlb...@gmail.com> wrote: > > > >> In a thread started by Vincent Lefevre in October [1] it was noted that > >> Subversion prints several pieces of information from the repository to the > >> terminal (including log messages and author names) without considering if > >> they may affect terminal behaviour. > >> > >> As demonstrated by DanielSh [2] a user may inject escape sequences into a > >> log message and when running svn log, these affect terminal color. Git > >> behaves the same way, as demonstrated by me [3]. > >> > > > > Any idea what Git is going to do with this? > > > > > Unless someone reports (reported?) it to the Git devs, it's possible they > aren't aware of it. > > If we want to do something about it on our end, it might make sense to > coordinate with the Git devs so that both systems could have similar > behavior. > > But... I'm not sure whether we want to do anything yet, partly because... > > > Can we reach consensus if this behaviour is intended, unintended but > >> desirable or unintended and undesirable? I would value the opinions of the > >> oldtimers who might have background information if this was ever discussed > >> or considered in the early days. > >> > >> In the original thread there were several arguments both pro and con > >> regarding filtering/quoting escape sequences. > >> > > > > From my perspective trying to do anything about this is opening up a huge > > investigation that may result in incompatible-with-history choices. > > > > 1. What about "svn diff" ? (any modifications here could break "patch", > > et. al.) > > 2. What about "svn cat" ? > > 3. What about properties? (I just verified you can place escape sequences > > in them). > > ... > > > > (I doubt my list above is complete.) > > > > > ...of concerns that doing so will break stuff. >
We have precedents for making breaking changes: we make them in an A.B.0 release if possible, and document them in the release notes and/or in notes/api-errata/. > > A "complete" implementation of a "feature" to mask/protect-against escape > > sequences is also going to need an option to enable the raw output > > (including the escape sequences) for every command/context where they could > > be coming out today. Not necessarily: If the lack of escaping may be considered a bugfix, then we don't have to offer a backwards-compatible upgrade path. The values of log messages are required to be UTF-8 strings. When ViewVC renders them, it escapes characters that are special to HTML (angle brackets and ampersand). If someone out there has a C source code generator that takes svn log messages as input, that generator should escape double quotes, backslashes, and so on when it emits C string literals derived from log messages. And when the cmdline client emits svn:log property values to a terminal, it should escape the sequences as appropriate for that terminal. And we needn't support an option to emit escape sequences in raw form for the same reason that ViewVC doesn't have an option to emit log messages into the HTTP response stream without HTML escaping. Cheers, Daniel
