בניות משוחזרות לאפליקציות VPN: מה מוכיח התאמה
בנייה מחדש תואמת מקשרת קובץ בינארי מופץ לקוד המקור ולכלים המוצהרים. היא אינה אומרת דבר על שירות ה-VPN שמאחורי אותו קובץ או על היומנים שלו.
שחזוריות היא תכונה של שרשרת האספקה: אותם קלטים מוצהרים חייבים להפיק את אותו חפץ. עבור לקוח VPN, הטענה הזו קושרת את המתקין שהורדת לקוד מקור ולשרשרת כלים שכל אחד יכול לבנות מחדש. היא אינה אומרת דבר על השירות שאליו הלקוח מתחבר.
השאלה השימושית היא אפוא צרה וניתנת למענה. האם הפרויקט מפרסם נוהל, והאם החפץ הספציפי שלך תואם אותו?
היכן בנייה מפסיקה להיות דטרמיניסטית
מהדרים מטמיעים חותמות זמן, נתיבים מוחלטים ושמות של מארחי בנייה, אלא אם כן מורים להם אחרת. ארכיונים רושמים את סדר הקבצים ואת זמני השינוי, מקשרים משנים את הפלט שלהם בהתאם לגרסת שרשרת הכלים, ודחיסה מקבילה יכולה לסדר מחדש בלוקים. כל אחד מאלה גורם לשתי בנייות של אותו קוד מקור להיראות שונה בבייטים בלי שום דבר מאיים שיקרה. דטרמיניזם מוטמע בבנייה בהנדסה, והוא לעולם אינו עובר בירושה כברירת מחדל.
פרויקט שטוען לשחזוריות חייב לנקוב בנרמול שהוא מיישם: חותמות זמן קבועות, נתיבים ממופים, רשומות ארכיון ממוינות, גרסאות מהדר ותלויות מוצמדות. בלי הרשימה הזו אי אפשר לפרש אי-התאמה, כי מרחב השונות הלגיטימית אינו מוגדר.
גם הקלטים המוצהרים חייבים להיות שלמים. כתובת מאגר בלי תג אינה גרסה, קובץ נעילה בלי hash אינו מערך תלויות, וסקריפט בנייה שמוריד כלי בזמן ריצה יש לו קלט שאיש אינו יכול להצמיד. כל פער הופך מאוחר יותר להבדל. השלימו את הרשימה לפני שמשווים משהו, כי רשימה חסרה אינה יכולה להיכשל באופן שמשמעותי.
| Input | How it drifts | What pins it |
|---|---|---|
| Source | Branch moves after release | Commit hash in the build metadata |
| Toolchain | Compiler patch level differs | Container image digest |
| Packaging | Archive order and mtimes vary | Normalised archive settings |
מה ההשוואה באמת בודקת
צד בלתי תלוי בונה מחדש בסביבה המוצהרת ומשווה את הפלט לחפץ שפורסם. זהות בייט-לבייט היא הצורה החזקה; שלב נרמול מתועד, שבו הבדל שנרשם מתהפך והתוצאות אז תואמות, הוא הצורה החלשה יותר אך עדיין השימושית.
ההשוואה עוסקת בקובץ הבינארי. חתימה עונה על שאלה אחרת: היא מקשרת מהדורה למפתח ומפתח לזהות, ולפרויקט יכולות להיות חתימות תקפות על חפצים שאיש לא בנה מחדש. שתי הבדיקות מצטברות זו על זו במקום להחליף זו את זו.
sha256sum wireguard-installer.msi gpg --verify wireguard-installer.msi.sig wireguard-installer.msi
הריצו את שתיהן לפני ההתקנה, והשוו את ה-hash לזה שפורסם עבור אותה מהדורה ואותה פלטפורמה. hash שתואם לעמוד הספק מוכיח שההורדה הגיעה שלמה; קובץ בינארי שנבנה מחדש ותואם ל-hash שפרסם הספק מוכיח משהו חזק יותר על האופן שבו נוצר.
למה אי-התאמה אינה הוכחה להתעסקות
רוב אי-ההתאמות מגיעות מקלט שאיש לא שלט בו. מהדורת תיקון אחרת של המהדר, נתיב בנייה שדלף לסמלי ניפוי שגיאות, לוקאל ששינה את סדר המיון, או שלב אריזה שהוחל אחרי ההשוואה — כולם מפיקים hash שונה מעבודה ישרה.
לכן יש לקרוא אי-התאמה מול הנוהל המתועד לפני שהיא הופכת לסיפור. אם הנוהל מצמיד הכול וההבדל נשאר בלתי מוסבר, זהו ממצא אמיתי שראוי להעלות בפני הפרויקט. אם הנוהל שותק בנוגע לאריזה, ההבדל עשוי להיות צפוי לחלוטין.
גם הסימטריה חשובה כאן: התאמה אינה מוכיחה שקוד המקור נקי מפגמים, רק שהקובץ הבינארי תואם לו. קוד שנבדק היטב וקוד בר-שחזור הם תכונות שונות, ופרויקט יכול להחזיק באחת בלי השנייה.
מה הטענה אומרת על השירות שמאחורי האפליקציה
הלקוח הוא תוכנית במכשיר שלך; השירות הוא שרתים, מערכות חשבונות ומדיניות שמירה במקום אחר. שחזוריות מגבילה את הראשון ואינה אומרת דבר על השני, ככל שהמתקין ייבדק בקפידה.
תצורת נקודת הקצה יכולה גם להשתנות לאחר ההתקנה, באמצעות הגדרות מרחוק או פרופיל שנשלט על ידי הספק. השינויים האלה מגיעים דרך הרשת ואינם מכוסים על ידי שום hash שחישבת לפני ההתחברות.
קראו את הטענה בהיקפה האמיתי, ואז בדקו בנפרד את השאלה השכנה: מה הספק רושם, ובאיזו סמכות שיפוט הוא עונה לבקשות. קובץ בינארי מאומת ושירות לא מאומת יכולים להתקיים זה לצד זה, וזה בדיוק המקרה שבדיקת שרשרת אספקה נועדה לחשוף ולא לתקן.