שְׁאֵלָה:
האם יש דרך לאמת בינארי מול המקורות?
flori
2013-07-05 17:44:53 UTC
view on stackexchange narkive permalink

נראה כי אין דרך מעשית לאמת את נתיב השלמות המלא של תוכנות מקובצות וארוזות מראש? אני יכול לבדוק את החבילה שהורדת עצמה באמצעות hashes, אך אין לי אימות אם הבינאריות המהודרות באמת מייצגות את קוד המקור הציבורי?

האם אין אפילו פיתרון תיאורטי לבעיה זו? במקרה הטוב דרך שניתן לבצע אוטומציה?

אולי לפרק אותה ולהשוות את הפלט או את hash שלה למשהו שספק התוכנה מציע?

מצאתי את הפוסט הנחמד הזה: http://blogs.kde.org/2013/06/19/really-source-code-software אז אולי אם המפיצים מקפידים יותר על הידור דטרמיניסטי, ברגע שאולי יהיה מנגנון שמקורו בקהל?
שתיים תשובות:
Tom Leek
2013-07-05 18:05:20 UTC
view on stackexchange narkive permalink

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

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

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


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

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

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

באשר למהדר, עיין ב מאמר קלאסי מאוד זה.

ל"פתרון הפשוט יותר "הבעיה כי הידור ממקור עשוי לעזור לך *, אך הוא לא יתפוס תוקף שמשתמש בבינאריות שהורכבו מראש ומדביק את 99% מהמשתמשים האחרים.
להבנה עד כמה קשה ניתוח קוד המקור, עיין בתחרות [Underhanded C Competition] (http://underhanded.xcott.com/).
תוספת קטנה לתשובה הנאה הזו: בפועל לא כל כך קשה לעקוף בינאריות מהימנות. לפחות עבור לינוקס יש לא מעט הפצות זמינות המבוססות לחלוטין על קוד המקור, למשל. ג'נטו ולינוקס מ- Scratch. כמובן שכל הנושאים האחרים נשארים כפי שציינת.
@CodesInChaos לכן אני אוהב לקבל אוטומציה.
flori
2017-02-26 05:07:53 UTC
view on stackexchange narkive permalink

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

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

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

זה לא ממש תיאורטי, [רוב חבילות דביאן ניתנות לשחזור] (https://wiki.debian.org/ReproducibleBuilds).


שאלה ותשובה זו תורגמה אוטומטית מהשפה האנגלית.התוכן המקורי זמין ב- stackexchange, ואנו מודים לו על רישיון cc by-sa 3.0 עליו הוא מופץ.
Loading...