הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה ומחשבים.
ספריית Boost.Locale התקבלה ב־Boost
הספריה Boost.Locale - ספרית לוקליזציה חוצת פלטפורמה התקבלה ב־Boost.
במהלך 16 ימי הבחינה התקבלו 15 סקירות שונות כאשר 10 מתוכם הצביע בעד שילוב הספרייה ב־Boost ו־5 נגד. במהלך הבחינה קיבלתי הרבה הערות בונות שרובן ייכנסו בגרסה הראשונה שתשולב ב־Boost.
עכשיו זה רשמי: Boost.Locale תיבחן לשילוב ב־Boost
עכשיו זה רשמי, תהליך הבחינה הפורמלית (Formal Review) של Boost.Locale לשילוב ב־Boost תיערך בין 7 ל־16 באפריל.
קצת רקע
Boost היא אוסף של ספריות C++ חופשיות המשפיע ביותר על הפיתוח המודרני של השפה. הוא מכיל עשרות רכיבים חשובים, שחלקם כבר שולבו בתקן הבא של C++ הידוע כ־C++0x בספריה הסטנדרטית. רבים מהם כבר ניתן למצוא בגרסאות האחרונות של קומפיילרים של GNU, Intel ושל Microsoft.
זהו פרויקט קהילתי שמפתח ספריות C++ שימושיות חוצות פלטפורמה. כל ספריה, כדי שהיא תשולב ב־Boost צריכה לעבור תהליך בחינה רשמית (formal review) שבמהלכו מפתחים שונים סוקרים את הספרייה בוחנים אותה: תיעוד, קוד, תכנון, מימוש ועוד ובסופו של דבר מצביעים האם כדאי לשלב את הספרייה בתוך Boost או לא.
התהליך מפוקח ע"י מנהל הבחינה (Review Manager) שבסופו של דבר מכריע על סמך קולות והערות המשתתפים אם לשלב את הספרייה ב־Boost או לא.
Chad Nelson, מפתח ספריית Xint התנדב להיות מנהל הבחינה, התאריך נקבע ועכשיו זה רשמי - Boost.Locale תעבור את תהליך הבחינה באפריל.
על הספרייה עצמה
Boost.Locale זאת ספריית לוקליזציה ותמיכה ביוניקוד שמקלה על בנאום ולוקליזציה. היא פותחה על בסיס ספריית ICU שמהווה היום את state-of-the-art בתחום היוניקוד וגם מאפשרת עבודה עם תמיכה מובנית בלוקליזציה שמערכות הפעלה מודרניות מספקות היום.
רכיבים:
- תרגום מחרוזות (על בסיס gettext)
- תמיכה במיון של טקסט
- פרמוט של תאריכים, מספרים, מטבע וכד' בהתאם ללוקל.
- תמיכה בלוחות שנה שונים (לא גרגוריאני) כמו לוח שנה עברי
- תמיכה טיפול מחרוזות כמו נורמליזציה
- תמיכה בחלוקת הטקס ליחידות כמו תווים, מילים, משפטים ועוד.
- תמיכה בהמרת קידוד הטקסט
ועוד
חשוב לציין שהיא עושה את זה בצורה חוצת פלטפורמה וגם מאפשר לבצע חלק נכבד מהמשימות האלה גם ללא תלות ב־ICU כך שהפרויקטים שלא דורשים תכונות מסובכות מידי יכולים לעבוד עם ספרייה מאוד קלילה ללא תלויות רבות.
שיהיה לי ולספריית Boost.Locale בהצלחה!
נ.ב.: ראוי לציין שהספרייה פותחה במקור עבור פרויקט CppCMS ואחרי שראיתי את התועלת שהיא יכול להביא לתחום הלוקליזציה החלטתי לעבוד בצורה הרבה יותר מאומצת ולהכין אותה ל־Boost.
נ.נ.ב.: לכל המעוניינים, בקרוב תשוחרר גרסה תיעוד הספרייה קצת יותר מועדכנים.
כיצד בונים מערכת פרוצה מרכיבים בטוחים קריפטוגרפית
אתמול שחררתי גרסאות CppCMS חדשות בשני הענפים - היציב וענף הבטא שסגרתי בהן באג שקשור לשימוש לא נכון ברכיבים קריפטוגרפיים.
תחילת הסיפור
הסמסטר אני לוקח קורס יסודות קריפטוגרפיה של פרופ' רן קנטי. במהלך הקורס דננו בנושא הצפנה והדרישות של בטיחות.
נגיד, יש לנו אלגוריתם שיודע להצפין בצורה בטוחה: היריב לא יוכל להשיג שום מידע על התוכן של הודעות בהסתכלות על טקסט מוצפן; ואז שואלים שאלות כמו האם זה מספיק, באיזה תנאים וכו'.
עכשיו, נחזור לבעיה שאני מנסה לפתור ב־CppCMS בעזרת הצפנה.
אני רוצה לשמור מידע (session) בצד הלקוח בעוגייה ואני רוצה להבטיח שני דברים:
- הלקוח לא ידע מה אני שומר אצלו.
הלקוח לא יוכל לשנות את המידע ששמרתי;
הגדרת יותר מדויקת: הוא לא יוכל ליצור session (עוגייה) עם מידע שאני לא יצרתי.
הפתרון:
ניקח תוכן שאני רוצה לשמור אותו, נחשב לו checksum בעזרת פונקציה hash ונצפין אותו יחד עם ה־hash. סביר להניח שאם אין יכולת להפוך את הטקסט לטקסט מוצפן ובחזרה אז לא ניתן גם ליצור משהו שהתוכן וה-hash שלו יהיו תואמים.
האם יש אנשים שחשבו כך והשתמשו בזה לפניי? בהחלט כן - פרוטוקול WEP עושה בדיוק את הדבר הזה! אז, כפי שאתם כבר בוודאי יכולים לנחש, מימשתי פתרון דומה ב־CppCMS כדי להבטיח שהלקוח לא ייצור session לא חוקי, רק שהשתמשתי בהצפנת CBC-AES וב־hash קריפטוגרפי ולא ב־CRC32 (כמו שזה היה ב־WEP).
למען הסר ספק, לא השתמשתי בשיטה הזו בגלל שראיתי שימוש בה ב־wep - אני יודע כי wep פרוץ
אז ההרצאה דנה בנושא הצפנה ובטיחות. במהלכה הוצג שהפתרון הזה לא נכון וכלל לא מבטיח בטיחות במקרה כללי! כיוון שלא הצלחתי במהלך ההרצאה להבין כיצד במקרה פרטי שלי אפשר לתקוף את המנגנון הזה, התחלתי לחפש ומצאתי מאמר מאוד מעניין שעוסק ניתוח בעיית ההצפנה ואימות הזהות ביחד ובודק פתרונות שונים.
מי שמעוניין יכול לקרוא את המאמר, אבל בגדול הוא מציג התקפה אמתית (יחסית פשוטה) כנגד השיטה כזו שעובדת עם הצפנה מבוססת CBC ו־hash שמוצמד לסוף התוכן. המאמר קובע כי כל שיטה שמסתמכת על hash פומבי לבדיקת אמתות לא תעבוד. המאמר ממליץ על אימות התוכן המוצפן בעזרת MAC שעובד עם מפתח נוסף.
מה שחשוב שניתן להוכיח בקלות שאם ה־MAC שלנו בטוח וההצפנה בטוחה אז השיטה הזו תהיה בטוחה גם כן.
המעשה
אחרי הבנתי שיש לי באג קריטי במערכת ניהול ה־session בשני הענפים של CppCMS התחלתי לעבוד על התיקון (שהוא בסה"כ תיקון פשוט) ושחררתי גרסה החדש עם התיקון הנדרש.
בדיעבד אני מאוד שמח שלקחת את הקורס הזה, למרות שהוא מסוג הקורסים המאוד תיאורתיים שבד"כ אני לא אוהב ועוסק בנושאים שיחסית רחוקים הקריפטוגרפיה מעשית.
מסתבר שגם כאן, כמו בבכל דבר, אין תחליף לבסיס תאורתי מוצק.
מסקנות
שימוש באלגוריתמים בטוחים לא מבטיח שום בטיחות אם משתמשים בהם בצורה לא נכונה. לכן, בכל פעם שאתה עוסק במשהו קשור לקריפטוגרפיה, אם יש לך אפשרות תן למומחה להסתכל על מה שעשית.
האם אפשר היה לעשות אחרת?
אני חשבתי על זה - אולי אני בכוח מנסה להמציא גלגל קריפטוגרפי המחדש?
אבל ככל שאני חושב יותר, אני מבין שכנראה בהינתן הידע והניסיון שיש לי, לא יכולתי לעשות משהו יותר טוב.
- לא קיים פתרון סגור (קרי ספריה) לבעיה שאני צריך, בד"כ ההצפנה ואימות הן חלק מפרוטוקולים קיימים כמו TLS או SSH והם ממומשים ספציפית עבורם בצורה של תקשורת כך שהמשתמש מקבל API דמוי socket וכל מה שיש למטה מוסתר.
- רוב הספריות נותנות מימוש לש פרוטוקולים קיימים או אבני בניין כמו AES או MAC שאתה אחראי לחבר אותם ביחד בצורה נכונה, כך למשל, אם אתה לא מאתחל נכון את iv באלגוריתם CBC אתה תיצור חור אבטחה בקלות.
- עשיתי כמיטב יכולתי והשתמשתי ברכיבים מוכנים, לא כתבתי מימושים של AES או של SHA1 מחדש, נעזרתי בקוד קיים בדוק ומתוחזק היטב.
הבעיה שהרכבתי את האלגוריתמים קריפטוגרפיים בצורה לא נכונה; ולמען האמת, אני לא הראשון ולא האחרון שעשה דבר כזה - היו גדולים לפני שעשו טעויות כאלה וגם יהיו אחרי.
בהסתכלות לאחור - נראה עשיתי באמת מה שיכולתי. אם לא הייתי מפתח קוד פתוח פרטי אלא מנהל פרויקט בחברה שמפתחת פרויקט כזה אז, הייתי מזמין מומחה כדי לעשות בדיקה לקוד ולהחלטות שעשינו.
רישיון CppDB השתנה ל־BSL/MIT
החלטתי לשנות את רישיון CppDB - ספריית קישוריות ל־SQL לרישיון יותר מתירני רישיון כפול: רישיון Boost או רישיון MIT לבחירתכם.
בגדול, אני הייתי שמח להישאר עם רישיון יחיד - רישיון Boost, אבל ספריית MySQL לא מכילה חריגה עבורו, אז הוספתי רישיון MIT כחלופה. כך שאם אתם משתמשים ב־CppDB וב־MySQL אתם צריכים לנהוג לפי דרישות רישיון MIT.
לשינוי הרישיון היו מספר סיבות:
- אני רוצה לנסות להכניס את הספריה בשלב מסויים ל־Boost, כך ששינוי הרישיון היה מתוכנן בכל מקרה.
- אני מקווה שזה ירחיב את כמות המשתמשים והתורמים לפרויקט ויתן פרסום ודחיפה נוספים ל־CppCMS.
כדי למנוע אי הבנות: CppCMS עדיין משוחרר תחת LGPLv3 וזה לא עומד להשתנות.
שוחררה גרסה 0.99.5 של CppCMS שמכילה כלי חדש למניעת XSS.
התכונה הבולטת שנכנסה לגרסה זו היא למעשה פילטר מניעת XSS שמבוסס על "רשימה־לבנה" וביצוע בדיקות רבות על HTML שמתקבל מהמשתמש. כלי כזה יאפשר שילוב בטוח של עורכי טקסט עשירים כמו TinyMCE אפליקציות מבוססות CppCMS.
כמובן שזה כלי חדש ודורש review ובדיקה של זמן.
כרגע המסנן מופעל במערכת ויקי של CppCMS ואתם מוזמנים לנסות ולהכניס קוד זדוני בארגז החול של הויקי ולעשות Code-Review לפילטר עצמו xss.cpp ו־xss.h.
אם אתם מצליחים לעקוף את פילטר ה־XSS המופעל בויקי, אנא דווחו לי באופן מידי
עדכון: בטעות "ארגז החול" היה סגור לאורחים - זה תוקן, כל אחד יכול לערוך אותו ללא הרשמה
