On Fri, Jun 03, 2022 at 11:26:58AM -0600, Theo de Raadt wrote:
> If we do this, I think we should document it somehow that the payload is
> massaged.
This has been in snapshots for 10 days. The only fallout I see, is
that regress has to be adapted.
ok?
bluhm
Index: usr.sbin/syslogd/syslogd.8
=
Ted Unangst wrote:
> I think not. If you intentionally store binary data in syslog (why?) you can
> use
> base64. The vis call is to prevent harm, not guarantee it's unambiguous.
> Lots of potential syslog calls are already ambiguous if the user provides
> inputs containing spaces. A structured
On 2022-06-02, Theo de Raadt wrote:
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 `
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
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
Hi,
We're sending log data in JSON format to a SIEM system and noticed a special
behaviour of
OpenBSD's syslogd concerning strings with backslashes that is unique to OpenBSD:
echo '{"msg": \"This is "a test\""}' | logger
results in the following string logged:
{"msg": "This is \\"a test\\""}
As
