linux-2.6.17.8

[alexander@…]

Version increment. Milestone set to future, because continued -stable releases are promised for linux-2.6.16, not 2.6.17, and it is important to have a kernel supported by upstream for stable LFS releases. I.e., I'd like to avoid the current "vulnerable and unfixable kernel in 6.1.1" issue.

[Matthew Burgess]

Now 2.6.17.1 with a security fix in the SCTP code. Release announcement at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0606.2/1181.html.

[Matthew Burgess]

Now 2.6.17.2. Release announcement at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0606.3/2734.html. Plenty of bug fixes, but none that look immediately security related.

[Matthew Burgess]

Now 2.6.17.3. Release announcement at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0606.3/2960.html. Fixes a remote crash in the SCTP code (CVE-2006-2934).

[Matthew Burgess]

Now 2.6.17.4. Fixes a local privilege escalation vulnerability in the prctl() system call. Release announcement at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0607.0/1726.html

[alexander@…]

Security update. Example exploit for old version is available at ​http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/047913.html (needs a.out binfmt support in the kernel, but there are other ways to exploit this).

[alexander@…]

This update is reported to break some versions of HAL.

[Matthew Burgess]

Now 2.6.17.7. Release announcement at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0607.3/0264.html. This includes a security vulnerability fix in the USB serial driver and an XFS corruption bug fix amongst others.

[Matthew Burgess]

update linux utf-8 patch

[Matthew Burgess]

Alexander, could you please check the attached patch to see if its correct? To give you an idea of where I might have messed it up, if you apply one of the 2.6.16 based utf-8 patches you'll see a couple of hunks are rejected which is where I've had to amend the patch by hand.

Thanks,

Matt.

[alexander@…]

I am not going to maintain the patch anymore (but ​http://lkml.org/lkml/diff/2006/5/9/40/1 applies to linux-2.6.17.x). Those who want proper Unicode input with dead keya and working copy-and-paste must install X window system.

[Matthew Burgess]

Alexander, thanks for your input. Looking at the comments in that patch (rejected upstream because of ioctl compatibility concerns) I'm inclined to drop it. Is the patch at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0608.0/1362.html related, or is that something completely different? (I really wish I understood i18n issues!).

[alexander@…]

The patch is for output, and its most useful effect is that the linux console starts printing a "bad character" glyph when it receives invalid UTF-8 sequences.

However, I doubt that it is useful for LFS. Anybody who is going to work with UTF-8 must install Xorg anyway and forget about the Linux console (however, we must document the Xorg requirement).

[nadavvin]

However, I doubt that it is useful for LFS. Anybody who is going to work with UTF-8 must install Xorg anyway and forget about the Linux console (however, we must document the Xorg requirement).

Does it mean that there no suport in utf-8 from the linux console?

It isn't good assumption since even if I use in graphical x, I do sometimes task in tty1. Since I use in hebrew, it's very important the support in all the levels.

[alexander@…]

UTF-8 support on the unpatched linux console exists, but is not fully usable.

Status as of unpatched 2.6.16:

• One can output UTF-8 text to the screen, assuming that it consists only of pre-combined single-width characters written from left to right, and that the loaded console font has them.
• Absolutely nothing is displayed in place of invalid UTF-8 sequences
• A workaround is implemented in ncurses for the fact that one cannot output "ESC ( 0" to switch to the line drawing mode (broken ACS).
• One can put the keyboard driver into Unicode mode, load a Unicode keymap, and get single keystrokes generate valid UTF-8 for non-ASCII characters.
• CAPS LOCK does not work (silently ignored) for non-ASCII.
• Composing and dead keys continue to produce single-byte characters, i.e. invalid UTF-8 (unusable)
• Copying and pasting non-ASCII characters is impossible

Status as of unpatched 2.6.17:

• One can output UTF-8 text to the screen, assuming that it consists only of pre-combined single-width characters written from left to right, and that the loaded console font has them.
• Absolutely nothing is displayed in place of invalid UTF-8 sequences
• A workaround is implemented in ncurses for the fact that one cannot output "ESC ( 0" to switch to the line drawing mode (broken ACS).
• One can put the keyboard driver into Unicode mode, load a Unicode keymap, and get single keystrokes generate valid UTF-8 for non-ASCII characters.
• CAPS LOCK does not work (silently ignored) for non-ASCII.
• Composing and dead keys can produce non-ASCII characters. They do this by assuming that the result should be converted from ISO-8859-1. This means that only characters present in Latin-1 can be produced by composing while the keyboard is in Unicode mode.
• Copying and pasting non-ASCII characters is impossible

Status as of patched 2.6.16 and patched 2.6.17 (i.e., LFS-6.2 + patch from Adam Tlałka, ​http://www.ussg.iu.edu/hypermail/linux/kernel/0608.0/1362.html):

• One can output UTF-8 text to the screen, assuming that it consists only of pre-combined single-width characters written from left to right, and that the loaded console font has them.
• A replacement "can't render this" glyph is displayed in place of invalid UTF-8 sequences
• A workaround is implemented in ncurses for the fact that previously one could not output "ESC ( 0" to switch to the line drawing mode, but this workaround is no longer needed.
• One can put the keyboard driver into Unicode mode, load a Unicode keymap, and get single keystrokes generate valid UTF-8 for non-ASCII characters.
• CAPS LOCK does not work (silently ignored) for non-ASCII.
• Composing and dead keys can be used to produce complex characters. The (normally useless in UTF-8 mode) application charset map is used to translate bytes from the composition table to Unicode. This approach allows to get characters outside of Latin-1 by means of composing, but doesn't allow an accent to be placed on top of a non-ASCII character (i.e., for Greek, there is no way to compose ' + α = ά). There is still more functionality than with unpatched 2.6.17, since 2.6.17 doesn't allow one to get ^{+ Z = Ž for Czech.}
• Copying and pasting non-ASCII characters is implemented via a hack that works in most cases but produces wrong results if more than one (similarly-looking) character is mapped to the same glyph in the screen font.

For Hebrew, composing and dead keys are not used, and the only relevant limitation is broken copy-and-paste. But it is broken in every distro except LFS.

[Matthew Burgess]

Now 2.6.17.8. Release announcement at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0608.0/1937.html.

[Matthew Burgess]

Upgraded in r7773.

[Jeremy Huntwork]

Milestone 6.3 deleted