יותר תלויות יותר בעיות

Nuke1985

Active member
בגדול xkcd2347 .

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

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

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

ראו לדוגמה את המקרה הזה, שאפילו מישהו הקים אתר שצוחק עליו.

מה עושים? אתם חושבים בכלל על האיכות של התלויות שלכם? יש איזה מדיניות בנושא? או שהולכים על ה"יהיה בסדר" הישראלי?
 

vinney

Well-known member
בחברה שלנו כל חבילת צד שלישי עוברת ביקורת בטחון וגם של העורכי דין (לא כל רשיון open source מקובל עליהם). זה בהחלט מגביל כמה קוד אנחנו יכולים "לגנוב" מSE, אבל מצד שני עוזר למנוע בעיות כדוגמאת מה שאתה מתאר. כן, חברה מאוד גדולה ומוסדרת, אני בהחלט יכול לראות איך בסטארטאפ של שני אנשים וחצי אף אחד לא יחשוב פעמיים לפני שהם דוחפים איזו ספריה עם פגם אבטחה שיפיל אותם או תנאי רשיון שיגרור אותם לבית משפט עוד 10 שנים...
 
נערך לאחרונה ב:

Nuke1985

Active member
בחברה שלנו כל חבילת צד שלישי עוברת ביקורת בטחון

מה בדיקה כזאת כוללת?

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

vinney

Well-known member
אני חושב שהם עוברים על כל שורת קוד. זה חברה שיכולה (וחייבת!) להרשות לעצמה. אנחנו גם תורמים הרבה קוד חזרה להרבה ספריות.
 

AnarchistPhilosopher

Well-known member
בגדול xkcd2347 .

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

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

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

ראו לדוגמה את המקרה הזה, שאפילו מישהו הקים אתר שצוחק עליו.

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

BravoMan

Active member
זה מונע סיכונים של קוד לא מאובטח או עם בגים
אתה יוצא מנקודת הנחה שהמתכנתים שלך מומחים בכל תחום.

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

לנושא השרשור עצמו:
XKCD מצחיקים, אבל לא בדיוק תורה מסיני.

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

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

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

אגב, צריך להבדיל:
לא בכל שפה, ולא בכל חברה, עושים שימוש "on-line" - מה שקרה עם right-pad זו בכלל הסתמכות על כך שה-client side ימשוך ב-Live בכל שימוש פיסת קוד משרת של מישהו אחר.

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

Nuke1985

Active member
לצורך העניין, OpenSSL לא בדיוק פרויקט קטן ואלמוני, ומה שקרה להם, קורה כל יום בכל קוד בתוך כל חברה פי 10.

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

vinney

Well-known member
לכן רצוי לכתוב כמה שאפשר יותר קוד בתוך החברה ולא ליבא מבחוץ, כן "להמציא את הגלגל" ! זה מונע סיכונים של קוד לא מאובטח או עם בגים או עם תנאי רישיון לא ברורים, וזה נותן לך שליטה על הקוד ולהתאים אותו בדיוק לצרכיך , אם אפשר גם את מערכת ההפעלה היינו רוצים לכתוב בעצמינו ( ואף עשינו זאת באחד המעבדים שלנו ).
לא. לא צריך להמציא את הגלגל.

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

vinney

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

קלייטון.ש

Well-known member
בפרויקטים שלי אני בהחלט כותב הכל מאפס. כל הקוד שיכול להיות שלי הוא שלי. אמנם אי אפשר באמת לכתוב הכל לבד. מי שכותב לדסקטופ תלוי בקומפיילר ותלוי בספריות סטנדרטיות ובמיוחד תלוי במערכת ההפעלה. מי שכותב לווב תלוי בדפדפן ובמנוע JS ובצד שרת הוא תלוי בשרת (אם כי אני בניתי בזמנו מערכת צד שרת ב-C++ ויצרתי גם את השרת עצמו, וגם אז הייתי תלוי ב-openssl). אבל מעבר לדברים הבאמת בסיסיים הכל לגמרי שלי. אפילו כתבתי לבד פונקציית pad. עד כדי כך.
 

vinney

Well-known member
כשתכתוב לבד את SSL דבר איתנו, זה שכתבת pad לבד צריך להרשים מישהו?
 

user32

Well-known member
מנהל
זה תלוי ברמת הסיכון שמוכנים לקחת. כשעבדתי בחברות ענק היתה מדיניות של אפס סיכונים. בSAP נאלצנו לממש RegEx בעצמינו כי החברה סירבה לאשר חבילת קוד פתוח של MIT (שנכתב ע"י סטודנטים בMIT). זה היה בתחילת המלניום כשקוד פתוח נחשב למילה גסה. מניח שהם טיפה נפתחו לזה מאז.

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

קלייטון.ש

Well-known member
זה תלוי ברמת הסיכון שמוכנים לקחת. כשעבדתי בחברות ענק היתה מדיניות של אפס סיכונים. בSAP נאלצנו לממש RegEx בעצמינו כי החברה סירבה לאשר חבילת קוד פתוח של MIT (שנכתב ע"י סטודנטים בMIT). זה היה בתחילת המלניום כשקוד פתוח נחשב למילה גסה. מניח שהם טיפה נפתחו לזה מאז.

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

user32

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

קלייטון.ש

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

user32

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

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

קלייטון.ש

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

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

BravoMan

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

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

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