|| ||Vasiliy Kulikov <segoon-AT-openwall.com> |
|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Re: [PATCH v2] kernel: escape non-ASCII and control characters in
|| ||Sun, 26 Jun 2011 23:06:22 +0400|
|| ||Andrew Morton <akpm-AT-linux-foundation.org>,
James Morris <jmorris-AT-namei.org>,
Namhyung Kim <namhyung-AT-gmail.com>,
Greg Kroah-Hartman <gregkh-AT-suse.de>,
Alan Cox <alan-AT-lxorguk.ukuu.org.uk>,
Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Article, Thread
On Sun, Jun 26, 2011 at 20:26 +0200, Ingo Molnar wrote:
> > > Also, i think it would be better to make this opt-out, i.e.
> > > exclude the handful of control characters that are harmful (such
> > > as backline and console escape), instead of trying to include the
> > > known-useful ones.
> > Do you see any issue with the check above?
> There were clear problems with the first version you posted and
> that's enough proof to request the exclusion of known-dangerous
> characters instead of including known-useful characters.
It doesn't proof anything. If I/someone else did a mistake with
blacklisting would you say it is enough proof to request the inclusion
of well-known allowed characters?
> A black list is well-defined: it disables the display of certain
> characters because they are *known to be dangerous*.
What do you do with dangerous characters that are *not yet known* to be
> A white list on the other hand does it the wrong way around: it tries
> to put the 'burden of proof' on the useful, good guys - and that's
> counter-productive really.
Really? I think strict API definition is productive, unlike using it
in cases where it looks like working, but creating tricky and obscure
Yes, drawing multicolor logs is funny, but ...egrrr... printk() is not
written for these things.
http://www.openwall.com - bringing security into open computing environments
to post comments)