On Wed, 2022-01-26 at 09:18 -0700, Theo de Raadt wrote:
> > However, as things stand interpretation can be broken with the base
> > tools. I can't fix garbage input.
>
> Your proposal builds a mechanism which encourages making decisions based
> upon parsing garbage input.
So let's just focus on m
> However, as things stand interpretation can be broken with the base
> tools. I can't fix garbage input.
Your proposal builds a mechanism which encourages making decisions based
upon parsing garbage input.
>From our diff:
+.It Fl H
+Use the hostname from the received message
+.Pq if detected
+i
Thanks for looking into this.
On Sat, 2022-01-22 at 10:05 -0700, Theo de Raadt wrote:
> > Note that this only adds the parsing, the rest of the current behaviour
> > of stays the same. I have another diff in the pipeline for allowing the
> > hostname in the message.
>
> I object to this process.
> Note that this only adds the parsing, the rest of the current behaviour
> of stays the same. I have another diff in the pipeline for allowing the
> hostname in the message.
I object to this process.
You want to add parsing code as a fait accompli. With no justification.
Then later on, spring on
Currently syslogd(8) doesn't support hostname parsing for incoming
messages. This means that if a sender adds a hostname to a message it
will be interpreted as progname. Additionally, when a message is being
relayed, or there's some form of NATting taking place the originator of
the message will be
