לקוח VPN בקוד פתוח: מה הקוד מוכיח ומה הוא אינו יכול
מאגר ציבורי הוא ראיה על קוד מקור, לא על הבנייה שהתקנתם או על השרתים שמאחוריה. התאימו את המהדורה, ואז הרחיבו את הסקירה.
הקוד פורסם, הרישיון נקי, והחיבור עדיין אינו ניתן לאימות מקצה לקצה. הפער הזה רגיל, והוא אינו שערורייה. פרסום קוד הופך רכיב אחד לבדיק על ידי אנשים שלא הוזמנו, וזו תכונה אמיתית ובלתי שגרתית. מכאן לא נובע שהקובץ הבינארי שהתקנתם הגיע מהקוד הזה, או שדבר ממה שהספק מפעיל בצד השני נבדק בכלל.
הפרידו את הרכיב מהמוצר
ארבעה דברים יכולים לשאת את תווית הקוד הפתוח, ולעיתים נדירות כולם פתוחים. אפליקציית הלקוח היא מה שאנשים מתכוונים אליו. יישום הפרוטוקול שמתחתיה הוא חפץ אחר, לפעמים ספרייה ולפעמים קוד בתוך העץ. תוכנת השרת היא השלישית, והתשתית של הספק עצמו, פורטל החשבון וכלי התמיכה הם הרביעי. כל אחד מהם יכול להיות פתוח או סגור באופן בלתי תלוי.
לכן אמירות כמו "האפליקציה שלנו בקוד פתוח" מתארות את הפריט הראשון ומשאירות את השאר ללא מענה, וזה לא חוסר יושר אלא יותר החלקה קטגוריאלית. השאלה המועילה היא איזה מאגר, באיזו תג, מתאים לרכיב שאתם מסתמכים עליו.
ההבחנה הזו גם מסבירה מדוע שני מוצרים עם לקוחות פתוחים זהים יכולים להציע הבטחות שונות מאוד. הלקוח הוא החלק שאתם יכולים לבדוק; התנהגות המפעיל היא החלק שעליכם להעריך בדרכים אחרות.
התאימו את הבנייה המותקנת לתג שפורסם
מאגר הוא תיעוד של כוונה; הקובץ הבינארי בדיסק הוא מה שרץ. סגירת הפער הזה היא תרגיל מכני, והיא מתחילה בזיהוי מדויק של מה שמותקן ולא של מה שדף ההורדה פרסם.
| Component | What inspection can show | What it leaves untouched |
|---|---|---|
| Client source | How profiles, packets and optional telemetry are handled | Whether the shipped binary matches that source |
| Build output | Whether a declared build reproduces a matching artefact | Whether the source is correct or the toolchain is clean |
| Server software | What the implementation is capable of logging | What the operator actually configures and retains |
| Account and support systems | Almost nothing, unless they are separately published | Everything about how those systems treat your data |
מטא-נתוני החבילה אומרים לכם את הגרסה ואת המקור, מה ששולל את המקרה הפשוט של חבילה מיושנת או מוחלפת. הם אינם אומרים לכם כיצד החבילה הזו הורכבה, ובדיוק לשאלה הזו קיימות בנייות משוחזרות כדי לענות. בנייות משוחזרות מאפשרות לצד בלתי תלוי לבנות מחדש מאותו מקור ולהשוות את הפלט בית אחר בית, כך שאי-התאמה הופכת לראיה ולא לחשד.
אפילו התאמה מושלמת מוכיחה פחות ממה שאנשים מקווים. היא מראה שהחפץ מתאים למקור ולמתכון הבנייה, לא שהמקור נקי מפגמים ולא ששרשרת הכלים ששימשה הייתה מהימנה. שניהם שווים ידיעה, אבל אלו טענות שונות.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgהיכן תסמין מתחיל בדרך כלל
התלונה שמעוררת את הקריאה הזו היא לעיתים רחוקות "הקוד סגור". היא בדרך כלל תצפית ספציפית: לקוח שמתקשר למקום בלתי צפוי, גרסה ששונה מהערות המהדורה, או תהליך תמיכה שמבקש יותר ממה שהמנהרה אמורה להזדקק לו. כל אחת מהנקודות הללו מצביעה על רכיב אחר.
תנועת רשת בלתי צפויה מהלקוח היא שאלה של קוד המקור של הלקוח, וניתן לענות עליה בקריאת נתיב הקוד שפותח את החיבור. אי-התאמת גרסה היא שאלת אריזה. תהליך תמיכה שמבקש מסמכי זהות הוא שאלה של מערכת החשבונות, ושום ביקורת לקוח לא תפתור אותה.
מתן שם לרכיב הופך חוסר אמון מעורפל לבדיקה ספציפית. לבדיקה ספציפית אפשר לענות, להתווכח איתה או לסגור אותה. החלופה היא חשד קבוע בלי שלב הבא.
מה הסקירה אינה יכולה להגיע אליו, ומה לעשות במקום
שמירת נתונים בשרתי הספק היא מחוץ להישג הלקוח. כך גם התנהגות של פורטל חיוב, ספק בדיקת הונאות או שולחן תמיכה ששומר קבצים מצורפים. סקירת לקוח שנמתחת ל"ביקרנו את השירות" מציגה טענה שהראיות אינן תומכות בה.
קראו מה המפעיל מפרסם על שמירה ובקשות, רשמו את התאריך, והתייחסו לזה כהצהרה של צד מעוניין ולא כמדידה. זו צורה חלשה יותר של ראיה, ולהיות מפורש לגבי ההבדל מועיל יותר מאשר לשדרג אותה בסיפור מחדש.
לאחר מכן השתמשו במה שיש לכם כקלט אחד מבין כמה: זהות המהדורה המותקנת, האם התוכנה מתוחזקת, כיצד הלקוח מוגדר, ומה המפעיל אומר על המערכות שלו עצמו. קוד פתוח מחזק את ההערכה הזו בנקודה אחת. הוא אינו מחליף את השאר.
טענת ביקורת צריכה תמיד למנות את רכיביה ואת גרסאותיה. אם דוח אינו יכול לומר איזה מאגר ואיזו בנייה הוא בחן, הוא מתאר כוונה ולא מוצר.