אבטחה ב-qub

תאריך תחילה: 23 בספטמבר 2026 גרסה: 1.1 — סקירת דיוק מול המימוש

לחוקרים — מדריך מהיר:

פרטים מלאים נמצאים ב§12 (גילוי מתואם).

מי אנחנו

qub.social מופעל על ידי VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. אזכורים של "qub", "אנחנו", "אותנו" ו"שלנו" מתייחסים לגוף זה.

איש קשר לאבטחה: support@qub.social עם קידומת הנושא [SECURITY].

1. הגישה שלנו

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

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

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

שלושה עקרונות מניעים כל החלטת תכנון:

2. מודל איום

2.1 ממה אנו מגנים

2.2 ממה איננו יכולים להגן

אנו כנים לגבי המגבלות שלנו. qub אינו יכול להתגונן מפני:

3. קריפטוגרפיה בצד הלקוח

בזרימת ההודעות הרגילה בדפדפן, הצפנת התוכן מתרחשת לפני בקשת ההעלאה. שני נתיבים מפורשים שונים מכך: Builder /api/v1/seal שולח בכוונה טקסט גלוי ואת K שיצר הקורא אל ה-Worker לחתימה בזיכרון, והעמדה/חתימה משותפת של פקט שולחת את הפקט המובנה והחתום לשירות כדי להשלים את החפץ הדו-צדדי. אין לבלבל אף אחד מהחריגים עם הצפנה מקצה-לקצה בנתיב הדפדפן.

3.1 הצפנת timelock

qub משתמש ב-tlock — הצפנה מבוססת-זהות מקושרת לסיבוב משואת drand עתידי. ההצפנה מתבצעת בדפדפן שלך באמצעות המפתח הציבורי של רשת drand; מפתח הפענוח משוחרר באופן ציבורי על ידי רשת drand רק כשהסיבוב היעד מושג. אף אחד, כולל אנחנו, אינו יכול לשחזר את מפתח הפענוח מראש.

אנו מכוונים לשרשרת quicknet:

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

3.2 הצפנה סימטרית

סכמת tlock עוטפת מפתח תוכן AES-256-GCM. AES-GCM מספק הצפנה מאומתת: ביט יחיד שהתהפך בטקסט המוצפן גורם לפענוח להיכשל, במקום לייצר טקסט גלוי משובש בשקט.

3.3 סריאליזציה קנונית

מבני פרוטוקול מסוריאלים באמצעות CBOR דטרמיניסטי (RFC 8949 §4.2 קידוד דטרמיניסטי מרכזי). שני מימושים המקודדים אותו מבנה לוגי מייצרים CBOR זהה. מטענים חתומים מלאים אינם דטרמיניסטיים: הצפנות tlock והעטיפה החיצונית משתמשות באקראיות טרייה. גיבוב הגוף מחושב על הבתים הגולמיים של הגוף, בעוד שהקידוד הקנוני מונע עמימות במבנים החתומים ובמבני הפורמט על-החוט שמסביב.

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

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

3.4 גיבוב גוף ושלמות לפני-חשיפה

כל מטען חתום נושא גיבוב SHA3-256 של בתי הגוף הגולמיים שלו. הגיבוב כבול ל-qub_id, וכאשר חתימת מחברוּת מופעלת גם לקלט החתימה V2. צופה מחשב אותו מחדש לאחר הפענוח ודוחה אי-התאמה.

מזהה התוכן בן 32 הבתים qub_id נגזר מתמונת-קדם בת 108 בתים המכסה את גרסת הפרוטוקול, סוג התוכן, חותמות הזמן של היצירה והפתיחה, חותמת זמן אופציונלית לתוצאה (או ערך האפס השמור שלה), סבב drand היעד, גיבוב הגוף ו-SHA3-256 של הכותרת האופציונלית המנורמלת ל-NFC. שער או CDN אינם יכולים לשנות באופן עקבי אף שדה כבול ועדיין לעבור גזירה מחדש. כותרות מוגבלות ל-100 נקודות קוד NFC ונדחות אם הן מכילות את המחלקה המשותפת של נקודות קוד עוינות/בקרה (כולל עקיפות bidi, תווי רוחב אפס, בלוק התגים, BOM, C0, C1 ו-DEL).

3.5 חתימה (ML-DSA-65)

חתימת כתיבה משתמשת ב-ML-DSA-65 (FIPS 204), סכמת חתימה פוסט-קוונטית מתוקננת על ידי NIST. בחרנו בכוונה בפרימיטיב פוסט-קוונטי לחתימה מאחר שתוכן חתום הוא קבוע: חתימה המאומתת היום חייבת עדיין להיות מאומתת עשרות שנים מעתה, כולל לאחר שמחשבים קוונטיים בקנה מידה גדול הופכים מעשיים.

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

אותו פענוח tlock בתוך הדפדפן חל בתוך ההטמעה של qub: כש-qub חתום מעובד דרך <qub-embed> בדף צד-שלישי, הפענוח עדיין מתרחש ב-iframe ההטמעה בדפדפן הצופה. ההטמעה אינה משנה את מודל האמון — תוכן גלוי לעולם אינו מפוענח בשרת qub.

3.6 ייחוס ציבורי — בהצטרפות

qubs חתומים אינם נושאים מצביע על-שרשרת ליוצרם אלא אם היוצר בוחר במפורש לצרף אחד. כשאתה חותם qub היישום הייחוסי פולט תג אחסון Author (טביעת אצבע הקסדצימלית בת 64 תווים של מפתח החתימה הציבורי שלך) רק כש"ייחוס ציבורי" מופעל בשלב בוחר התאריך. עם המתג כבוי — ברירת המחדל — שום תג Author אינו נכתב וה-qub אינו מיוחס באחסון קבוע: שום דבר באחסון אינו מקשר את ההעלאה לכינוי שלך, לדוא"ל שלך, או ל-qubs האחרים שלך. עם המתג דולק, טביעת האצבע נפתרת ל-@handle שלך דרך שרשרת האימות ב§6.3 / §10 וספירת הצופה לאחור מציגה "נחתם על ידי @{handle}" לפני החשיפה.

זוהי הגנה מכוונת מפני סיכון המנייה שתג Author דולק-תמיד היה יוצר: צד שלישי הלומד את טביעת האצבע של יוצר יכול אחרת לחפש באחסון קבוע לפי התג ולשחזר את כל התפוקה ההיסטורית של אותו יוצר. ייחוס בהצטרפות סוגר ערוץ זה — רק qubs שהיוצר בוחר במפורש לייחס מופיעים תחת טביעת אצבע באחסון קבוע.

דף הפרופיל /u/{handle} הוא כרטיס זהות מאומתת — כינוי, שם תצוגה + כתובת URL אופציונליים, תווית "דוא"ל מאומת" (ללא כתובת), והצורה הקצרה של טביעת האצבע הקריפטוגרפית. הוא אינו מפרט את ה-qubs של יוצר. מבקרים הרוצים לראות qub מסוים מיוצר עוקבים אחר כתובת ה-URL למשלוח של אותו qub ישירות.

3.7 עטיפת הצפנה חיצונית

גם לאחר שפענוח timelock אפשרי מתמטית—ברגע שחתימת drand של הסבב הכבול פורסמה—שכבת ה-timelock הקנונית לבדה הייתה מאפשרת למאנדקס לפענח בכמות גדולה qubs ניתנים לגילוי. המסירה הפרטית סוגרת ערוץ זה באמצעות שכבה סימטרית נוספת סביב הבתים המוצפנים ב-timelock (פרוטוקול §13). המסירה הפומבית משמיטה בכוונה את העטיפה כדי שקישורי התראה, הטמעה וגילוי יוכלו לפעול ללא מקטע סודי.

העטיפה משתמשת ב-AES-256-GCM, צופן מאומת מתוקנן על ידי NIST, עם מפתח טרי בן 256 ביט K המיוצר לכל qub על ידי ה-CSPRNG של הדפדפן שלך. K כבול ל-qub_id של ה-qub כנתון נוסף מאומת, כך שמפתח מ-qub אחד אינו יכול לשמש מחדש לפענוח qub שונה.

בזרימת הדפדפן הפרטית הרגילה K לעולם אינו מגיע לשרתים שלנו. הוא מקודד למקטע ה-URL של קישור השיתוף (https://qub.social/c/<tx_id>#<base64url(K)>). דפדפנים אינם משדרים מקטעי URL לשרתים—RFC 3986 ממקם את המקטע מחוץ לבקשה—כך ש-qub.social, שערי אחסון, רשתות CDN וניטור בקשות עיוורים ל-K בזרימה זו. ה-OuterWrapper המאוחסן הוא CBOR מובנה שניתן לזהותו, אך שדה הטקסט המוצפן המאומת שלו מסתיר את מבנה ה-SealedQub הפנימי ואי אפשר לפתוח אותו ללא K.

תוצאות נטו:

נקודת הקצה בצד השרת של ה-Worker /api/v1/seal (בשימוש סוכני בינה מלאכותית וקוראי API אחרים) מחייבת את הקורא לייצר את K באמצעות CSPRNG, לשמור אותו מקומית ולספק אותו כ-wrapper_key_b64url. ה-Worker בהכרח רואה גם את הטקסט הגלוי וגם את K בזיכרון בנתיב מהימן-במפורש זה, אך אינו שומר אף אחד מהם. Idempotency-Key חובה מונע מתגובה אבודה ליצור qub שני מחויב, בעוד ש-K השמור בידי הקורא יכול להשתלב עם כתובת ה-URL המשוחזרת חסרת-המקטע. זה שונה מנתיב הדפדפן ברירת-המחדל, שבו K לעולם אינו מגיע אל ה-Worker אלא אם היוצר מפעיל שחזור במפורש.

4. תעבורה וקצה

4.1 TLS

תעבורת דפדפן אל qub מוגשת ב-HTTPS בקצה Cloudflare. התגובות מגדירות HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). גרסת TLS וחבילת הצופן המדויקות שנקבעות במשא ומתן נשלטות בידי תצורת הקצה הפעילה ולא נטענות על ידי קוד היישום. איננו חושפים שרת מקור נפרד שניתן להגיע אליו.

4.2 אבטחת תוכן

הלקוח המהודר מוגש עם כותרות סוג-תוכן ומטמון קפדניות. מעטפת ה-SPA היא מקור יחיד. איננו מטמיעים סקריפטים של צד-שלישי לניתוח או פרסום. שתי נקודות המגע של צד-שלישי במוצר הן שתיהן מתוחמות בצמצום: זרימת הרכישה עוזבת את ה-SPA כליל עם הפניית עמוד-מלא לקופה המתארחת ב-Stripe (https://checkout.stripe.com/…) — ממשק Stripe לעולם אינו מבצע במקור שלנו ואיננו רואים נתוני כרטיס — וזרימת החתימה טוענת את ווידג'ט Turnstile של Cloudflare, חלופת CAPTCHA שומרת-פרטיות ש-Cloudflare מעבדת בתוך iframe בארגז חול משלה. אף צד אינו יכול לקרוא את שאר הדף.

ה-iframe המוטמע של qub (מוגש מ-qub.social/embed/{tx_id} ונטען לאתרי צד-שלישי על ידי embed.js) נושא Content-Security-Policy משלו. רשימת ההיתר של connect-src היא 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh ו-https://drand.cloudflare.com. ה-iframe רץ עם sandbox="allow-scripts allow-top-navigation-by-user-activation" (לא allow-same-origin): דף המארח אינו יכול לקרוא את ה-DOM שלו, והוא אינו יכול לנווט את המארח אלא לאחר פעולת משתמש.

4.3 CORS והיקף Fetch

לקוח הדפדפן מבצע בקשות fetch רק ל:

יעדי ההטמעה נאכפים באמצעות ה-CSP שלה. היעדים המיועדים של ה-SPA הראשי קבועים בקוד ובתצורה ונבדקים בבדיקות דפדפן ואינטגרציה; Subresource Integrity אינו אמצעי בקרה על יעדי רשת.

ההטמעה שולפת בתים מאוחסנים דרך מקורות qub/אחסון שברשימת ההיתר, פותחת מטענים פרטיים בדפדפן באמצעות K ממקטע ה-URL שלה, ושולפת חתימות סבב בזמן החשיפה משני מקורות drand שברשימת ההיתר. ה-SPA הראשי משתמש בקבוצת הגיבוי בת ארבע נקודות הקצה שב-config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh ו-api3.drand.sh) כדי שכשל בנקודת קצה אחת לא יחסום חשיפה. ה-CSP של ההטמעה דוחה חיבורים מחוץ לרשימה המפורשת שלה.

5. תשתית בצד השרת

5.1 קצה ללא-שרת

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

מתווך CORS ציבורי נפרד חל Access-Control-Allow-Origin: * לזיהוי הנתיב המיושם הבא: /embed.js, /embed/v1.js, הכל תחת /embed/; /api/v1/telemetry; /api/v1/openapi.json; הכל תחת /api/v1/qub/ (כולל בייטים, מטה-דאטה, הוכחה, מעורבות, הודעה ודחיפה של מסלולים משנה); הכל תחת /api/v1/log/; ניהול פניות ציבור תחת /api/v1/handle/; ואווטאר ציבורי קורא למטה /api/v1/identity/avatar/.רישיונות הטיסה המקדימים שלו GET, POST, ו OPTIONS עם ה Content-Type כותרת בקשה. הממשק הזה המבוסס על קידומות רחב יותר מהקריאות שהשתל כרגע מבצע, ולכן כל מנהל מתחת לאותן קידומות חייב להמשיך לאכוף את האימות, האותנטיקציה, מגבלות הקצב ובקרות השימוש לרעה שלו. מסלולי API אחרים מקפידים על מדיניות CORS המוגבלת של qub.social.

5.2 אחסון

זרימת ההודעות הרגילה בדפדפן אינה שומרת טקסט גלוי בתשתית qub. הנתיב Builder /api/v1/seal מטפל בטקסט גלוי וב-K בזיכרון אך אינו שומר אף אחד מהם. העמדת פקט שומרת בהכרח את הפקט המובנה והחתום עד לחתימה המשותפת, לביטולו או לפקיעתו. שחזור בהצטרפות שומר יכולת מסירה (הקישור המלא הנושא מקטע) כדי שאפשר יהיה לשחזרו מאוחר יותר. לכן איננו מתארים את שכבת האחסון כולה כ"מטא-נתונים בלבד".

5.3 סודות

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

5.4 רישום וטלמטריה

יומני JSON מובנים נכתבים בכל בקשת API עם מזהה התאמה החשוף בכותרת התגובה X-Request-Id. טלמטריית לקוח אנונימית — ללא מזהה מכשיר, ללא כתובת IP, ללא תצוגה מקדימה של תוכן. אירועים מאוחסנים זמנית בזיכרון ומועברים על בסיס מאמץ-מיטבי; העברה שנכשלה מושמטת, לא מנוסה שוב. טלמטריה מתוכננת להיות ניתנת-להשבתה בשכבת הרשת מבלי להשפיע על המוצר.

6. אימות

6.1 כניסה בקישור קסם

הכניסה משתמשת באסימון חד-פעמי החתום ב-HMAC הנמסר לתיבת הדוא"ל. הקישור תקף ל-15 דקות, והפדיון נתבע אטומית כך ששימוש מקביל או חוזר נכשל במצב סגור. בהצלחה הדפדפן מקבל עוגיית __Host-qub_session אטומה עם המאפיינים Secure, HttpOnly, SameSite=Strict ו-Path=/.

להפעלות יש מגבלת חוסר פעילות של 30 יום ומגבלה מוחלטת של 90 יום, הן מסתובבות לאחר 24 שעות ומקבלות רק את הדור הקודם המיידי למשך תקופת חסד של 120 שניות לתגובה שאבדה. שינויי חשבון רגישים דורשים אימות בעשר הדקות האחרונות. סוד החתימה HMAC הוא קישור פלטפורמה; קריאת מטא-נתונים בלבד אינה מאפשרת כשלעצמה ליצור אסימון תקף.

6.2 מפתחות API (שכבת מפתחים)

מפתחות API למפתחים משתמשים בקידומת qub_sk_ לזיהוי וחיפוש-קל. כל מפתח:

נקודות קצה לניהול מפתחות מנהלתיות מוגבלות מאחורי אישור מנהל נפרד.

6.3 אימות דוא"ל (חתימת כתיבה)

קישור כתובת דוא"ל למפתח חתימה דורש:

  1. החזקת מפתח החתימה הפרטי (אתה חותם על אתגר)
  2. החזקת תיבת הדוא"ל (אתה מזין קוד בן 6 ספרות הנמסר בדוא"ל)

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

7. תשלומים

הזנת הכרטיס ועיבודו מתבצעים בקופה המתארחת ב-Stripe. לעולם איננו מקבלים מספרי כרטיס, תאריכי תפוגה או CVCs. אנו שומרים מזהי לקוח ומינוי של Stripe, מצב מינוי ונתוני תקופה ברשומות זכאות/מפתחות API כדי ליישב גישה, חידושים, מדידה, ביטולים והחזרים. הצהרות הפרטיות והאבטחה של Stripe חלות על טיפולו בנתוני התשלום.

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

8. עמידות בפני ניצול לרעה

8.1 זיהוי בוטים

זרימת החתימה מוגבלת על ידי חלופת CAPTCHA שומרת-פרטיות שאינה משתמשת בעוגיות למעקב ואינה לוקחת טביעת אצבע לפרסום. אתגר שנכשל נדחה על ידי ה-Worker בקצה שלנו לפני שמתבצע כל עיבוד בצד החתימה.

8.2 הגבלת קצב

מגבלות קצב נאכפות בכמה שכבות:

מונים ותביעות אטומיות מפוזרים בין KV, Durable Objects וקישורי הגבלת קצב של הפלטפורמה בהתאם לדרישות העקביות של נקודת הקצה. בקשות מוגבלות-קצב מחזירות 429; נקודות קצה המסוגלות לחשב חלון ניסיון חוזר כוללות Retry-After.

8.3 מודרציית תוכן

נתיב ההעלאה בדפדפן כברירת מחדל אינו יכול לסרוק את הגוף: הוא מקבל רק את החפץ שנאטם על ידי הלקוח. הבונה /api/v1/seal הנתיב רואה טקסט ברור באופן זמני, ושלב ההסכם מחזיק בתנאים מובנים עד הסיום, אך אותם חריגי אמון אינם הופכים את נתיב ההעלאה הכללי העיוור לבייט לסורק תוכן. הפיקוח התפעולי הוא רשימת דחייה בשכבת הצופה: qub ברשימת דחייה נדחה על ידי הצופה שלנו ללא קשר לכך שהמטען המאוחסן נשאר נגיש. הרשימה השחורה אינה משיבה בתים עמידים, רשומות יומן שקיפות, או נתוני רשת קבועים שכבר פורסמו.

דיווחי ניצול לרעה מוגבלי-קצב באמצעות גיבוב חד-כיווני של ה-IP של המדווח; איננו מאחסנים IPs בגלוי למטרה זו.

9. שרשרת אספקה ושלמות בנייה

9.1 הצמדת ערכת כלים

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

9.2 בדיקות סטטיות וניתוח סטטי

סביבת העבודה מאפשרת את קבוצות הבדיקות הקפדניות ביותר שלנו ברמת deny. CI מתייחס לכל אזהרה — כולל אזהרות קישורי-תיעוד — ככשל בנייה. זה מכוון: אנו משתמשים בקפדנות הבדיקה כחוט-מעידה לנסיגות עדינות.

9.3 שערי CI

תהליך העבודה של CI מכסה עיצוב ובדיקות סטטיות מחמירות; בדיקות Rust, WASM/דפדפן, Worker, הטמעה ו-API; בדיקת סוגים; כיסוי קוד; בדיקות מוטציה/אינווריאנטות; ניתוח סטטי של תלויות ותהליכי עבודה; בדיקות מפתחות i18n, כיסוי, סחף ונקודות קוד עוינות; עדכניות תיעוד, API ובסיס ידע שנוצרו; מלאי מסמכים וקישורים פנימיים; תקציבי גיליון סגנון וחבילה; ואימות OpenAPI. כמה עבודות מוטציה יקרות מתוזמנות במקום לרוץ בכל דחיפה.

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

9.4 בדיקת מוטציה

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

9.5 ווי Git

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

10. בדיקות

קוד קריטי-לאבטחה נושא שלושה סוגי בדיקות:

11. היגיינת ענף ושחרור

ענפי תכונות מקדמים את staging רק דרך בקשת משיכה בשער 1: ci הנדרש ירוק, אין בקשת שינוי לא פתורה או התנגשות מיזוג, והעץ הנסקר נקי; המיזוג מתבצע כ-squash והענף נמחק. main מתקדם רק דרך בקשת המשיכה של שער 2, staging → main, ושומר מוצא באמצעות merge commit. דחיפות ישירות לענפים אינן תהליך השחרור.

פריסות סטייג'ינג וייצור מופעלות ממצבי הענפים המוגנים המתאימים staging ו-main לאחר CI. קוד בבקשות משיכה והרשאות של מזלגות אינם מקבלים סודות פריסה.

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

12. גילוי מתואם

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

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

12.1 נמל מבטחים

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

נמל מבטחים זה חל על:

הוא אינו חל על הנדסה חברתית של חברי צוות qub, בדיקות מניעת-שירות, או גישה לנתונים של משתמשים אחרים מעבר למה שדרוש להדגמת הבעיה. אם אינך בטוח אם משהו נופל בתוך נמל המבטחים, שאל קודם באמצעות אותה קידומת נושא [SECURITY].

13. מגבלות כנות

אבטחה היא נוהג, לא מצב. כמה מגבלות שוות לנקוב בהן ישירות:

14. שינויים בדף זה

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

לשאלות לגבי כל דבר בדף זה, שלח דוא"ל ל-support@qub.social עם קידומת הנושא [SECURITY].

15. יומן שינויים

גרסה תאריך תחילה סיכום
1.1 23 בספטמבר 2026 התאמת הטענות הקריפטוגרפיות, מצבי המסירה, האחסון, CSP, הפעלות, מפתחות API, תשלומים, CI ותהליך השחרור למערכת הממומשת.
1.0 2 במאי 2026 פרסום ראשוני.