On 02.06.2022 - 08:49:41, Theo de Raadt wrote: > The purpose of the vis() addition was mostly to guard against later > "cat" views of the output files sending remote-controllable escape-codes > to terminals (especially in xterm, there are many unfortunately features > which should not be reachable from remote. the nastiest features were > disabled over decades, and some bugs were fixed, but some nasty escape > codes remain). > > But please consider this impact of the change you propose. > > There is one additional flag, VIS_NOSLASH, which inhibits the doubling of > backslashes and the backslash before the default format (that is, control > characters are represented by `^C' and meta characters as `M-C'). With > this flag set, the encoding is ambiguous and non-invertible. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This means if syslog is used to send some 'binary data', and you later on > want to decode meaning "unvis" the block, that won't work. Is that a usage > case to worry about?
Hi Theo, I', totally aware that with VIS_NOSLASH we get ambiguous encodings that are hard to cope with and can lead to problems. But as noone else seems to do this I would say that no one that parses syslog stuff is prepared to handle messages escaped in the OpenBSD way. In our case we have those JSON encoded log strings sent by filebeat to Elasticsearch and it does not correctly unescape those messages. I image a lot of other tools would have the same problem, as as I said, this behaviour seems unique to OpenBSD and no one is prepared for it. If you're strongly against this change in general, maybe ain additional command line switch for syslog could be a solution so you can decide if you want the secure escaping variant or not. If you prefer this route, I can send another diff. Greetings, Matthias
smime.p7s
Description: S/MIME cryptographic signature
