linux-kernel - Re: [PATCH] update checkpatch.pl to version 0.03

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Jun 2007 14:39:42 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	jcm@...masters.org, Jan Engelhardt <jengelh@...putergmbh.de>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Andy Whitcroft <apw@...dowen.org>,
	Andrew Morton <akpm@...l.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Joel Schopp <jschopp@...tin.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.03

On Fri, Jun 08, 2007 at 11:52:19AM +0100, Alan Cox wrote:
> > The problem is that the second byte is interpreted as a control code.
> > 
> > Is there any trick to get the shell working again in this situation?
> > The cursor hangs, and I've not yet found a trick to do anything in this
> > xterm again (except for killing it from another xterm).
> 
> For gnome terminal just select 'reset terminal' in the menu or escape-[c;
>  (from memory) is the VT reset code. If your xterm can be stuck forever
> file a security bug against your vendors xterm for a DoS attack problem.

Someone else already told me this trick, and the "Full Reset" from the 
Control + middle mouse button menu works with my xterm.

Not a problem if you know about it or if you have time.

> > > "Require" is a rather strong word for a print formatting issue specific
> > > to obscure setups.
> > 
> > See obove, it's not only "print formatting", it's "kills my shell".
> 
> It printed a symbol, if your shell really got screwed that much by it
> then your shell needs work perhaps.

My shell is bash...

> I'm not btw arguing that we shouldn't
> teach the tools to be more polite, just that its hardly a "requirement"

For tools like ls or vim that have to deal with every kind of charset 
confusion for ages such issues have already been shaken out.

But tools don't expects the kernel to output non-ASCII strings.

It's not only about MODULE_AUTHOR, if you consider it rude to limit 
people's names to ASCII, then don't forget that we have printk's like
    Linux agpgart interface v0.102 (c) Dave Jones

What happens if the maintainer changes and it's now
     Linux agpgart interface v0.103 © Dave Ønes

Does the console handle it correctly during boot?
Can all tools that process the syslog cope with it?

Perhaps the answer is in both cases "yes", but it's a completely 
untested area.

We really must have all bugs shaken out and all users using fixed tools 
_before_ we can start outputting UTF-8 - limiting people's names to 
ASCII in not ideal, but IMHO causing breakages for users is a much 
bigger problem.

> Alan

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/