תגית: תוכנה חופשית

research

קוד פתוח, קוד בטוח?

אילן שביט תוהה האם תכנה פתוחה1 היא בטוחה יותר יותר או מתכנה קניינית.

אני חסיד של תכנות פתוחות. כאשר אני בוחן תכנות פתוחות מול תכנות קנייניות, התכנה הפתוחה תמיד מתחילה עבורי מנקודת יתרון, ועל התכנה הקניינית להציג יתרונות מהותיים על מנת להתחרות. אחד השיקולים הוא אבטחת מידע.

קוד פתוח איננו בטוח יותר מקוד סגור מעצם מהותו. קוד בטוח הוא תוצר של שיטות עבודה ובקרת איכות.  יתר על כן, מרבית המשתמשים קוראים או מהדרים קוד בעצמם, אם משתמשים במוצר הסופי. מרבית כשלי האבטחה אינם מתגלים בתהליך הפיתוח אלא במהלך יישום החושף את התכנה לעולם האמיתי.

לתכנה מבוססת על קוד פתוח יתרון בתחום אבטחת המידע המצבים שתהליך הפיתוח הוא הוא פתוח:

  • קבוצות דיון או רשימות תפוצה גלויות הדנות בתכנה
  • ניהול באגים  גלוי לקהל הרחב
  • גילוי נאות

לשיקול המסחרי יש משקל2, וחברות המתבססות על מודל מסחרי קנייני בלבד סובלות מחסרון. הודאה בכשל בטיחותי לו אין להן פתרון זמין יוצר סיכון כלכלי ומשפטי חמור יותר. חברות אלו נוטות יותר להסתיר פגמים מאשר לחשוף אותם עד למציאת פתרון. תהליך זה מתארך, כאשר התכנה תלויה ברכיבים קנייניים של יצרנים אחרים. לקוד פתוח יתרון משום שאת העזרה למציאת הפתרון ניתן לקבל גם מחוץ למסגרת של צוות הפיתוח המיידי.

מעט מאוד מערכות מידע הן אי של קוד המסוגל לקיים את עצמו. תכנה משתמשת בספריות של מערכת ההפעלה, ברכיבים של תכנה אחרת ומתממשקת מול תכנות אחרות. לעיתים כשל אבטחה הוא חלק מהתוכנה, לעיתים כשל של מערכת תומכת או נלוות, לעיתים היישום הוא הבעיה, ולעיתים קרובות רק האינטראקציה היא זאת החושפת את כשל האבטחה.

באחד הבנקים בישראל ישנה מערכת המבוססת על Windows NT 4.0. לא ניתן לשדרג את המערכת היות ואחת מתת המערכות היא מוצר קנייני של חברה שפשטה את הרגל, ואותה תת מערכת איננה פועלת במערכות מתקדמות יותר3 של Microsoft. המערכת תכתב מחדש מתישהו מול תת מערכת חדשה. אם ברשות הבנק היה קוד המקור אל אותה תת מערכת, אין זאת אומרת שבהכרח היה הבנק מתחזק את הקוד בעצמו, אך ניתן היה אולי למצוא מתחזק אחר.

  1. אני כאן מערבב מעט בין המושגים של קוד פתוח ותכנה חופשית []
  2. ויש לא מעט חברות מסחריות התבססות על קוד פתוח []
  3. דהיינו כאלו שזוכות לעידכוני אבטחה []
api
feed

הסכנה לא בטכנולוגיה

יהונתן קלינגר מציג השינויים החשאיים שמיקרוסופט ביצעה כחלק מתהליך האוטומטי של Windows כחלק מטענה להמנעות של שימוש ממשלתי בקוד קנייני.
לפי הידוע לי, השינויים האמורים פעלו רק במצב בו לא התבצעו עידכונים אוטומטיים, אך המשתמש בחר לסמן את אפשרות הבדיקה של קיום עדכונים. אני, ואחרים, חושבים שהתגובה חריפה מדי.

מידה ועובדה זו נכונה, השינויים יכולים להיות מהותיים להמשך אפשרות הבדיקה (למנוע מצב של ביצה ותרנגולת, שבו המערכת לא יכולה לבדוק יותר קיום עדכונים כי מערכת העדכון השתנתה).מיקרוסופט מאפשרת (בתנאים מסיימים), לראות (אם כי לא לשנות) קוד. מעט מאוד בחרו לממש אפשרות זאת. יתר על כן, הרתיעה של ארגונים רבים מויסטה נובעת מהתלות של מוצר זה בתקשורת מול מיקרוסופט.

מיקרוסופט סובלת מבעיה של חוסר עמינות הן בצד העסקי, והן בצד הטכנולוגי. אבל שתי בעיות אלו אינן בהכרח תלויות אחת בשניה. וניסיונות לתקן בעיה בצד אחד מובילות לפעמים לבעיה בצד השני. תסבוכת זאת הולכת וגדלה כאשר לא ברור אם מיקרוסופט היא חברת של טכנולוגיה, מוצרי צריכה או בידור.

בחזונו של תומס ווטסון הייתה מכונה של IBM בכל חברה, ו"שלום דרך מסחר". דא עקא, שעם כל מכונת IBM הגיעו אנשי IBM, והמסחר כלל גם מסחר עם גרמניה הנאצית. את IBM הורידו מגדולתה חברות כמו NCR, דיגיטל ומיקרוסופט, לא האגודה לזכויות האזרח.

קוד פתוח איננו התשובה לכל, ואיננה החרב לפתרון כל הקשרים הגורדיים של אבטחת מידע וצנעת הפרט ללא מי שיבחן את הקוד.

advertise
careers

אל המטרות שלפניכם, בקוד פתוח, אש!

לכבוד חגיגות (?) 60 שנה לקלשניקוב1, סוקר הרג'יסטר את תולדות הרובה, ומגיע למסקנות הבאות:

  • הצלחתו של הקלשניקוב נובעת מפרסום המפרטים הטכניים בצורה חופשית, שאיפשרה את יצורו ופיתוח על ידי מדינות רבות.
  • פיתוח רובה הסער, ועצם שמו, נובע מסיבות פוליטיות, לא פחות מסיבות טכניות.

היה בכוונתי להאשים את את הרג'יסטר בשנאת ישראל, היות ובשתי הסקירות לא הופיע משוש תע"שנו, הגליל. אך היות ובקריאה שניה התברר כי גם אחיו הבוגר, הוולמט 62 הפיני איננו מופיע, אני מיחס זאת לעודף של צאצאים של ה-AK47, יותר מאשר העדפה פוליטית.

לענין שמות ופוליטיקה, תמיד שיעשע אותי העובדה כי את המאוזר 98 בחרנו לכנות "צ'כי", ואת ה-MG34, "מגל"ד". ניתן להבין כי לא רצינו את השמות הגרמניים, אך מדוע דווקא לאויה 109, שרכשנו מצ'כיה, קראנו מסרשמידטים?

ומה לזה ולמערכות מידע? כלום. למעט הקביעה של הרג'יסטר שהקלשניקוב הוא: More like communism than Linux

  1. הרובה, לא האיש []
support

קוד פתוח כנייר הלקמוס

כאשר אני מגלה אתר חדש, אני פותח אותו בשועל האש. כאשר אני בוחן מערכת העובדת עם מסמכים, אני מנסה אותה מול OpenOffice.

ישנם עוד דפדפנים וישנן עוד חבילות משרדיות. המטרה שלי איננה לבדוק תאימות של התכנה לכל סביבה אפשרית, אלא את נכונות המפתח להתמודד מול סביבה משתנה וצרכים משתנים. אני חסיד של מערכות הבנויות לפי סטנדרטים פתוחים. ומערכות קוד פתוח נוטות יותר לכוון זה.

הנטיה של מפתחי קוד פתוח לסטנדרטים פתוחים איננה רק אידאולוגית, אלא גם טכנית. פרויקטים רבים הם קטנים או מורכבים מקהל של מפתחים המפוזרים גאוגרפית ובין חברות שונות. שמירה על סטנדרטים מבטיחה שיתוף פעולה בתוך הפרויקט ובין פרויקטים.

הדבקות בסטנדרטים פתוחים יכולה להיות דראקונית לא פחות מדבקות בטכנולוגיות קנייניות. הראיה היא בקושי להתמודד עם דואר זבל תוך שמירה על פרוטוקול SMTP המשמש למשלוח דואר מקדמת דנא.

סטנדרטים פתוחים יכולים גם לקום מסביבות קנייניות. מבנה ה-PDF של Adobe הוא דוגמה מצויינת לכך. כיום ניתן לייצר ולקרוא קבצי PDF ללא כל שימוש בכלים מבית היוצר של Adobe.

מה הערך המוסף למשתמש. בקצרה: אריכות ימים. סטנדרטים מאריכים ימים יותר מטכנולוגיה. שינויים בסטנדרטים מלווים בתהליך ביקורת חיצוני מקיף יותר, ועל פי רב כוללים תיעוד רב יותר של ההבדלים והשינויים.

אין זה מפתיע, אם כן, שפרויקטים של מעבר אל ומ-MS-SQL, ושידרוגי גרסאות בסביבה זו הם מהירים ובעלי פחות נטיה לכשלים מפרויקטים דומים על סביבת MS-Access. שניהם מוצרים מבית תוכנה קינייני וסגור, אך MS-SQL הוא מוצר התואם לסטנדרטים של ANSI-SQL, ו-MS-Access לא.

כמובן, התמונה לא תמיד פשוטה כל כך. לשועל האש ול-Internet Explorer (כמו גם לדפדפנים אחרים) יש נטיה לפרש תגיות סטנדרטיות בצורות שונות, כך שהיישום הוא לא פחות חשוב מהסטנדרט.

report

שלושים שנה…

מדי פעם אני נתקל או משתתף בדיון "האם לינוקס (או תוכנה חופשית בכלל) מוכן (אן מתאים) לשולחן העבודה או לסביבה הארגונית?".

בתגובה אני נוטה לשאול "האם המחשב האישי מתאים לשולחן העבודה?"

מאמר ב-CIO Insight, מעלה את השאלה ונותן פרספקטיבה של 30 שנה באמצעות המצגת הבאה:
הביטו במצגת, וחישבו. האם היא כל כך שונה מאלו שאתם רואים היום?