TlwgTypo Font

แนวคิดหนึ่งที่เกิดขึ้นระหว่างร่วมทำสุริยัน คือการปรับฟอนต์ monospace ของไทย จากที่เคยแยกเป็น monospace แท้ (เช่น TlwgMono) ที่ทุก glyph กว้างเท่ากันหมด ไม่เว้นแม้แต่สระบน-ล่าง กับ monospace เทียม (เช่น TlwgTypewriter และ TlwgTypist) ที่ให้ glyph ของสระบน-ล่างกว้างเท่ากับศูนย์ นอกนั้นกว้างเท่ากันหมด มาเป็นฟอนต์ monospace ชุดเดียว ที่วาดได้ทั้งสองแบบ

แนวคิด ได้มาจาก DejaVu ที่เขาทำ glyph เป็น monospace แท้ แต่ใช้ OpenType feature ในการปรับแก้ความกว้างของ combining mark ให้เป็นศูนย์ ซึ่งจะทำให้ฟอนต์มีคุณสมบัติเป็น monospace ในขณะที่ยังวาดเครื่องหมายบน-ล่างได้อย่างถูกต้อง

เพื่อเป็นการทดลองแนวคิด ผมได้สร้างฟอนต์ใหม่ต่างหาก ตั้งชื่อเล่น ๆ ก่อน ว่า TlwgTypo โดยดัดแปลงจาก TlwgTypist โดยทำใน TLWG CVS แล้วใช้ในโครงการสุริยัน ผลคือ โปรแกรมเทอร์มินัลอย่าง konsole ที่มีการแพตช์ให้วาดภาษาไทยจัดระดับ สามารถวาดได้โดยไม่ต้องมีกรณีพิเศษ และความแตกต่างอีกอย่างคือ สำหรับเทอร์มินัลที่ยังไม่รองรับภาษาไทยแบบจัดระดับ เช่น gnome-terminal ก็วาดภาษาไทยแบบ monospace จริง ๆ

gnome-terminal ที่ใช้ TlwgTypist จะจัดระดับแค่บางส่วน แล้วมีช่องว่างคั่น เพราะเครื่องหมายบน-ล่างถูกเลื่อนไปที่เซลล์ก่อน:

แต่ถ้าใช้ TlwgTypo จะเป็น monospace ล้วน ในลักษณะเดียวกับฟอนต์ monospace แท้อย่าง TlwgMono:

จะให้ดี ก็ควรแก้ gnome-terminal (โดยทำที่ vte widget) เพื่อให้แสดงภาษาไทยแบบจัดระดับ แต่ในระหว่างที่ยังไม่แก้ ก็เป็นตัวอย่างให้เห็นได้ ว่าฟอนต์ monospace แท้กับเทียม ทำงานต่างกัน

ทีนี้ มาถึงประเด็นสำคัญ ว่ามันยังวาดภาษาไทยแบบจัดระดับเหมือน TlwgTypist ในโปรแกรมทั่วไปได้หรือเปล่า ต่อไปนี้คือภาพหน้าจอของ TlwgTypo เมื่อใช้ leafpad (GtkTextView) และ epiphany (Gecko):

ใน CVS snapshot ปัจจุบัน TlwgTypo ยังเป็นฟอนต์แยกต่างหากจาก TlwgTypist อยู่ เพื่อประโยชน์ในการทดลอง แต่เพื่อไม่ให้มีฟอนต์ซ้ำซ้อนกันมากเกินไป ผมกำลังคิดว่าจะแทนที่เนื้อหาของ TlwgTypist ด้วย TlwgTypo เสีย ให้เหลือแต่ TlwgTypist ที่ใช้เทคนิคใหม่อย่างเดียว รวมทั้งอาจจะทำอย่างเดียวกันกับ TlwgMono/TlwgTypewriter ด้วย แต่คงต้องทดสอบให้แน่ใจอีกนิด

บางที thaifonts-scalable รุ่นหน้า อาจ merge แค่ TlwgTypist ก่อน แล้วทิ้ง TlwgMono + TlwgTypewriter ไว้เป็นตัวเลือกสำรองสำหรับผู้ใช้ ในกรณีที่มีปัญหากับซอฟต์แวร์ตัวไหน

Update: พบโปรแกรมที่มีปัญหาแล้วครับ OO.o เจ้าเก่า ดูเหมือนจะมีปัญหากับฟอนต์พื้น ๆ อย่าง TlwgMono ด้วย T_T

ส่วนชุด GNOME Office ไม่มีปัญหา ทั้ง AbiWord (2.6) และ Gnumeric

Thanks

ขอขอบคุณ บ. 101 Global จำกัด ที่หย่อนสตางค์ลงหมวกครับ บริษัทนี้ เป็นบริษัทเดียวกับที่บริจาคเครื่องเซิร์ฟเวอร์สำหรับ debianclub ด้วย ขอให้กิจการรุ่งเรืองนะครับ

OpenSSL Weak Key

ไม่ได้ blog เสียนานด้วยเหตุผลหลาย ๆ อย่าง การสลับงานไปมาหลาย ๆ อย่างก็ส่วนหนึ่ง กิจกรรมของครอบครัวก็อีกส่วนหนึ่ง ขี้เกียจเขียนก็อีกส่วนหนึ่ง เอิ๊ก

ได้ข่าว DSA 1571-1 จากนิวตรอนเมื่อวันก่อน เล่นเอาวุ่น เมื่อมีการพบความหละหลวมของกุญแจที่สร้างโดย openssl ของ Debian/Ubuntu ตั้งแต่รุ่น 0.9.8c-1 เป็นต้นมา โดยเป็นแพตช์เฉพาะของ Debian มีผลตั้งแต่ etch เป็นต้นมา

ก่อนหน้านั้นไม่กี่ชั่วโมง ก็ได้รับแจ้งจาก alioth admin ว่าจะลบ SSH public key ทั้งหมดออกจากเซิร์ฟเวอร์ เพราะปัญหานี้

อีกไม่กี่ชั่วโมงถัดมา บล็อกโนเนะก็ ออกข่าว นี้เหมือนกัน

พอรู้ว่าอะไรเป็นอะไร ก็รีบนึกทันที ว่ามีการสร้างกุญแจไว้ที่ไหนบ้างในช่วงที่ผ่านมา แต่เพื่อความแน่ใจ ก็ตรวจสอบแก้ไขตาม คำแนะนำ เสีย แล้วก็เขียน สรุปขั้นตอนสำคัญ ไว้ที่ debianclub ด้วย

อาการของปัญหาคือ กุญแจที่สร้างจาก openssl รุ่นที่มีปัญหา มีความเป็นไปได้ในการสุ่มเพียง 32767 หรือ 2^15 แบบ ซึ่งอยู่ในวิสัยของการโจมตีแบบ brute force ได้ ดังนั้น ระบบใด ๆ ก็ตาม ที่ผู้ใช้เอากุญแจสาธารณะ SSH ดังกล่าวไปติดตั้งไว้ ก็มีสิทธิ์ถูกเจาะระบบในลักษณะการเดารหัสผ่านได้

ดังนั้น อย่างที่ Erich Schubert (DD คนหนึ่ง) ได้ blog ไว้ ปัญหานี้จึงไม่ได้กระทบแค่ผู้ใช้ Debian/Ubuntu เท่านั้น แต่ระบบ Linux, FreeBSD หรือ Unix ใด ๆ ที่ผู้ใช้ Debian/Ubuntu มีบัญชีอยู่ และเอากุญแจสาธารณะไปติดตั้งไว้ ก็มีสิทธิ์ถูกเจาะได้ทั้งนั้น จึงขอฝากเตือน admin ทั่วไปที่ไม่ได้ใช้ Debian/Ubuntu ด้วย ว่าอย่านิ่งนอนใจ

ล่าสุด Debian ได้ออกแพกเกจ openssh-blacklist เพื่อปิดกั้นการเข้าระบบผ่านกุญแจที่หละหลวมทั้งหมดแล้ว เป็นมาตรการอีกขั้นหนึ่ง ที่ distro อื่นสามารถใช้ช่วยแก้ปัญหาได้ แต่สำหรับผู้ใช้ Debian/Ubuntu คุณควรเปลี่ยนกุญแจก่อนที่จะอัปเกรด openssh (คืออัปเกรดแค่ openssl/libssl เพื่อสร้างกุญแจใหม่ก่อน แล้วเปลี่ยนกุญแจให้เรียบร้อย แล้วค่อยอัปเกรด openssh เพราะไม่งั้น กุญแจของคุณจะโดน blacklist ก่อนจะทันได้เปลี่ยน)

สำหรับรายละเอียดของปัญหา Daniel Leidert ซึ่งเป็น DD คนหนึ่ง เขียนอธิบาย ไว้ค่อนข้างดี คือผู้ดูแลแพกเกจ openssl ได้พยายามแก้ปัญหาการใช้ uninitialized memory ใน openssl ตามที่ตรวจพบโดย valgrind โดยไม่รู้ตัวว่า ได้ตัดแหล่งข้อมูลสุ่มสำคัญของ openssl ไป คือในการสุ่มกุญแจ openssl จะใช้ข้อมูลสุ่มจากหลาย ๆ แหล่ง เพื่อเพิ่ม entropy โดยแหล่งหนึ่งที่ใช้ คือบัฟเฟอร์หน่วยความจำที่ไม่มีการกำหนดค่า (uninitialized memory) นี้เอง พอถูกตัดออกไป ก็เหลือข้อมูลสุ่มอื่นอยู่บ้าง แต่อัตราการสุ่มได้ต่ำลงจนอยู่ในวิสัยที่จะเจาะแบบ brute force ได้ (คนที่พบบั๊กนี้คือ Luciano Bello)

อ่านแล้วก็สงสัยเหมือนกัน ว่ามีการใช้วิธีนี้ในโปรแกรมด้วย.. จำได้ว่าตอนสร้างกุญแจ gpg จะต้องเก็บข้อมูลจาก event ต่าง ๆ ด้วย เช่น ให้ขยับเมาส์มั่ว ๆ หรือสลับหน้าต่าง/หน้าจอไปมา ทำไม openssl ไม่ใช้วิธีนั้นบ้าง?

ว่าแต่ว่า คุณได้ตรวจสอบหรือยัง ว่าคุณโดนปัญหานี้ด้วยหรือเปล่า?

Thanks

ขอขอบคุณ คุณหน่อย อีกครั้ง ที่ หย่อนสตางค์ลงหมวก ให้ผมเมื่อต้นเดือน ขอให้รวย ๆ นะครับ :)

พอดีง่วนอยู่กับการเขียน paper ฉบับหนึ่งอยู่ เลยไม่ได้ blog เสียนาน ขออภัยที่ขอบคุณช้าไปหน่อยครับ