It is nice that this problem is “solved” for this repository. But the real problem still exists. How do you sign, and what is the source for the key to verify the signature with.
So my first stab at that problem would be to make use for the git builtin signing mechanism. Discourse would then need to keep track of the signer of an installed plugin. If that changes it should warn the admin.
This obviously has a lot of holes in it.
Where to get the signer’s keys from? Metadata in plugin.rb and about.json. Keyservers are nice… but quite complicated. Or… meta.discourse.org serves as keyserver, so authors should register their public keys.
Only verify the most recent commit? Probably sufficient, can’t do much about stolen keys
But if a key is stolen, how to check revocation? If meta serves the key, that problem could be solved.
This is great for the admin ui, but what about the plugin installs in a docker container? Save previously accepted singing keys in shared, and add a verification step to the rebuild. Probably a pre-build check to prevent taking the system down and then rejecting the clone; and then a post checkout check just in case somebody messed with the repo in the meantime?
What about old unsigned repos? Big warning that its content cannot be verified. + yes/no/cancel prompt
has responsibilty. The Server Owner should make sure that some Server loads the desired code. Whether that be pointing the blame at GitHub, upstream to their TLD (e.g. .com), or further downstream
אבל הפוך את העבודה שלי, כמנהל מערכת, לקלה יותר. אני, כמפתח תוספים, רוצה להקל על העבודה שלך.
כיום, שדרוג נותן אמון מוחלט ב-URI המקור. זה מטריד אותי, מכיוון שהוכח שהמקור (github) אינו אמין, במיוחד לא בשלבים מסוימים בבנייה מחדש של קונטיינר. הזהיר אותי, כמנהל מערכת, כאשר יש שינוי ביחסי האמון.
אני, כמנהל מערכת, בדקתי כל תוסף או רכיב ערכת נושא לפני שהוספתי אותו. לאחר מכן, Discourse נותן לי מעט מאוד הנחיה בבדיקה. היום הייתי צריך לבנות מחדש את הקונטיינר שלי, מה שישכפל מחדש את כל התוספים. אני די חסר שליטה, אלא אם כן אבצע שינוי מתקדם בהגדרה כדי לקבע גרסה.
זה עשוי לעבוד עבורי, כמפתח תוכנה רגוע ברגע שאצטרך לבצע תחזוקה. אבל אלו די מגבלות. בנוסף להפיכת Discourse לפלטפורמה נהדרת לדיון. אנחנו צריכים גם להפוך אותה לפלטפורמה בטוחה טכנית לדיון. תוספים שנפגעו יכולים לגרום נזק חמור. רכיבי ערכות נושא שנפגעו יכולים לגרום נזק משמעותי.
אני חושב שזה הגיוני מאוד. יש לנו SRI עבור Javascript, MS Authenticode עבור Windows.
היו הרבה התקפות שרשרת אספקה על, למשל, NPM ו-RubyGems.
הדבר היחיד שמדאיג אותי הוא שיהיה מחסום לאנשים לקבל את רכיב התוסף או הנושא שלהם “מאושר”, כמו איך Microsoft Smartscreen מונע ממשתמשים להריץ תוכנות פחות מוכרות ממפתחים בודדים.