Bảo mật tại qub

Ngày có hiệu lực: 23 tháng 9 năm 2026 Phiên bản: 1.1 — rà soát độ chính xác trong thực hiện

Dành cho các nhà nghiên cứu — tham khảo nhanh:

Chi tiết đầy đủ có trong §12 (Công bố phối hợp).

Chúng tôi là ai

qub.social được vận hành bởi VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. Các tham chiếu đến "qub", "chúng tôi" và "của chúng tôi" có nghĩa là pháp nhân đó.

Liên hệ về bảo mật: support@qub.social với tiền tố tiêu đề [SECURITY].

1. Cách tiếp cận của chúng tôi

qub là hạ tầng tin cậy. Sản phẩm sẽ vô giá trị nếu nó không an toàn, vì vậy bảo mật không phải là một tính năng — nó là nền tảng. Trang này mô tả, bằng những thuật ngữ cụ thể, cách chúng tôi bảo vệ ngăn xếp công nghệ, dữ liệu của bạn và tính toàn vẹn của nội dung được niêm phong.

Giá trị của một cam kết thời gian có thể xác minh tăng lên khi ngày càng nhiều phần của internet được tạo ra bởi máy móc. Một giao dịch lưu trữ đã được xác minh hoặc một mỏ neo nhật ký minh bạch có thể xác nhận rằng bản mã hóa đã tồn tại không muộn hơn thời gian khối của nó; hiện vật đã bị niêm phong riêng biệt chứng minh tính toàn vẹn của nội dung, ràng buộc vòng drand, và bất kỳ chữ ký tác giả nào. Giữ các khẳng định đó tách biệt là tiêu chuẩn mà trang này được giữ.

Chúng tôi không yêu cầu bạn tin tưởng chúng tôi. Chúng tôi thiết kế để mức độ tin cậy yêu cầu từ chúng tôi càng nhỏ càng tốt, và khi sự tin cậy được yêu cầu, chúng tôi giải thích chính xác những gì đang được tin cậy và tại sao.

Ba nguyên tắc thúc đẩy mọi quyết định thiết kế:

2. Mô hình Mối đe dọa

2.1 Chúng tôi bảo vệ chống lại điều gì

2.2 Chúng tôi không thể bảo vệ chống lại điều gì

Chúng tôi trung thực về các giới hạn của mình. qub không thể bảo vệ chống lại:

3. Mật mã Phía Máy khách

Trong luồng thông điệp của trình duyệt mặc định, việc mã hóa nội dung xảy ra trước khi gửi yêu cầu tải lên. Hai đường đi rõ ràng khác nhau: Builder /api/v1/seal cố tình gửi văn bản thuần và K do người gọi tạo ra cho Worker để niêm phong trong bộ nhớ, và việc chuẩn bị/ký kết pact gửi pact có cấu trúc đã ký cho dịch vụ để nó có thể hoàn tất hiện vật song phương. Không ngoại lệ nào nên bị nhầm lẫn với mã hóa đầu-cuối theo đường dẫn trình duyệt.

3.1 Mã hóa Khóa Thời gian

qub sử dụng tlock — mã hóa dựa trên danh tính được khóa với một vòng beacon drand trong tương lai. Mã hóa tiến hành trong trình duyệt của bạn sử dụng khóa công khai của mạng drand; khóa giải mã được phát hành công khai bởi mạng drand chỉ khi vòng mục tiêu được đạt đến. Không ai, bao gồm cả chúng tôi, có thể tái cấu trúc khóa giải mã trước thời gian.

Chúng tôi nhắm đến chuỗi quicknet:

Khóa công khai của chuỗi quicknet và thời gian khởi nguồn được biên dịch vào máy khách. Chúng tôi không lấy các tham số chuỗi vào thời gian chạy, vì vậy một nút độc hại không thể thay thế bằng một chuỗi chúng tôi kiểm soát.

3.2 Mã hóa Đối xứng

Lược đồ tlock bao bọc một khóa nội dung AES-256-GCM. AES-GCM cung cấp mã hóa được xác thực: một bit duy nhất bị lật trong bản mã làm cho việc giải mã thất bại, thay vì tạo ra văn bản gốc bị hỏng âm thầm.

3.3 Tuần tự hóa Chuẩn tắc

Các cấu trúc giao thức được tuần tự hóa bằng CBOR xác định trước (RFC 8949 §4.2 mã hóa xác định cốt lõi). Hai triển khai mã hóa cùng một cấu trúc logic sẽ tạo ra CBOR giống hệt nhau. Các tải trọng được niêm phong hoàn chỉnh là không deterministic: tlock và mã hóa outer-wrapper sử dụng ngẫu nhiên mới. Băm thân được tính trên các byte thân thô, trong khi mã hóa chuẩn hóa làm cho các cấu trúc đã ký/dây xung quanh không gây hiểu nhầm.

Chúng tôi viết bộ mã hóa CBOR bằng tay cho cả triển khai máy khách và máy chủ của chúng tôi thay vì dựa vào một thư viện tuần tự hóa chung — yêu cầu là tính chính xác, không phải tiện lợi, và các thử nghiệm thuộc tính chạy trong cả hai triển khai để xác minh chúng đồng ý.

Một thử nghiệm hồi quy khẳng định rằng định dạng truyền dẫn chuẩn tắc không chứa chuỗi byte thương hiệu qub nào vượt quá khóa trường nguyên thủy giao thức qub_id. Định dạng truyền dẫn cố ý không phụ thuộc thương hiệu — bất kỳ trình xem tuân thủ nào (của chúng tôi hoặc của bên thứ ba) có thể hiển thị bất kỳ qub nào từ nơi lưu trữ vĩnh viễn, bất kể triển khai nào đã niêm phong nó. Thử nghiệm là một dây bẫy ngăn chặn một thay đổi trong tương lai vô tình nhúng một tham chiếu thương hiệu vào các byte mà, một khi đã ở trong nơi lưu trữ vĩnh viễn, không thể được viết lại.

3.4 Băm Nội dung và Tính toàn vẹn Trước Công bố

Mỗi phần payload được niêm phong đều mang theo một hàm băm SHA3-256 của các byte dữ liệu thô của nó. Hàm băm này được liên kết vào qub_id và, khi việc ký tác giả được kích hoạt, vào đầu vào chữ ký V2. Người xem sẽ tính lại sau khi giải mã và từ chối nếu không khớp.

Định danh nội dung 32 byte qub_id được tạo ra từ một preimage 108 byte bao gồm phiên bản giao thức, loại nội dung, dấu thời gian tạo và mở khóa, dấu thời gian kết quả tùy chọn (hoặc giá trị sentinel bằng 0 của nó), vòng drand mục tiêu, băm thân bài, và SHA3-256 của tiêu đề được chuẩn hóa NFC tùy chọn. Một cổng hoặc CDN không thể thay đổi bất kỳ trường ràng buộc nào một cách nhất quán và vẫn vượt qua việc tái tạo lại. Các tiêu đề bị giới hạn ở 100 điểm mã NFC và bị từ chối nếu thuộc lớp ký tự thù địch/điều khiển chung (bao gồm ghi đè bidi, ký tự chiều rộng bằng 0, khối thẻ, BOM, C0, C1 và DEL).

3.5 Ký (ML-DSA-65)

Ký quyền tác giả sử dụng ML-DSA-65 (FIPS 204), một lược đồ chữ ký hậu lượng tử được chuẩn hóa bởi NIST. Chúng tôi cố ý chọn một nguyên thủy hậu lượng tử để ký vì nội dung được niêm phong là vĩnh viễn: một chữ ký xác minh được hôm nay phải vẫn xác minh được hàng thập kỷ sau đó, bao gồm sau khi các máy tính lượng tử quy mô lớn trở nên khả thi.

Các khóa ký được tạo ra trong trình duyệt. Bí mật cục bộ được bao bọc dưới một khóa WebCrypto không thể trích xuất trước khi lưu trữ trong IndexedDB. Nếu tính năng khôi phục chéo thiết bị theo tài khoản được sử dụng, một khối khóa di động được mã hóa AEAD sẽ được lưu trữ phía máy chủ; ciphertext của khóa bí mật được liên kết với ID tài khoản không thể thay đổi, và dịch vụ xác thực phong bì công khai nhưng không thể giải mã dữ liệu bí mật. Các byte khóa riêng thô không được gửi đến máy chủ. Các khóa công khai và ghi nhận xác thực được lưu trữ để xác minh và hiển thị danh tính.

Cùng việc giải mã tlock trong trình duyệt áp dụng bên trong nhúng qub: khi một qub đã niêm phong được hiển thị thông qua <qub-embed> trên trang của bên thứ ba, việc giải mã vẫn diễn ra trong iframe nhúng trong trình duyệt của người xem. Nhúng không thay đổi mô hình tin cậy — văn bản gốc không bao giờ được giải mã trên máy chủ qub.

3.6 Ghi nhận Công khai — Tùy chọn

Các qub đã niêm phong không mang con trỏ trên chuỗi đến người tạo của chúng trừ khi người tạo rõ ràng chọn đính kèm một. Khi bạn niêm phong một qub, ứng dụng tham chiếu phát ra một thẻ lưu trữ Author (một dấu vân tay hex 64 ký tự của khóa công khai ký của bạn) chỉ khi "Ghi nhận công khai" được bật tại bước chọn ngày. Với công tắc tắt — mặc định — không có thẻ Author nào được viết và qub không được ghi nhận trong nơi lưu trữ vĩnh viễn: không có gì trong kho lưu trữ liên kết tải lên với tên người dùng của bạn, email của bạn, hoặc các qub khác của bạn. Với công tắc bật, dấu vân tay phân giải đến @handle của bạn thông qua chuỗi xác nhận trong §6.3 / §10 và đếm ngược của trình xem hiển thị "Đã niêm phong bởi @{handle}" trước khi công bố.

Đây là một biện pháp bảo vệ cố ý chống lại rủi ro liệt kê mà một thẻ Author luôn bật sẽ tạo ra: một bên thứ ba học được dấu vân tay của một người tạo có thể tìm kiếm nơi lưu trữ vĩnh viễn theo thẻ và tái cấu trúc toàn bộ đầu ra lịch sử của người tạo đó. Ghi nhận tùy chọn đóng kênh đó — chỉ các qub mà người tạo rõ ràng chọn ghi nhận xuất hiện dưới một dấu vân tay trong nơi lưu trữ vĩnh viễn.

Trang hồ sơ /u/{handle} là một thẻ danh tính đã được xác minh — tên người dùng, tên hiển thị tùy chọn + URL, viên "email đã xác minh" (không có địa chỉ), và hình thức rút gọn dấu vân tay mật mã. Nó không liệt kê các qub của người tạo. Khách truy cập muốn xem một qub cụ thể từ một người tạo trực tiếp theo URL bàn giao của qub đó.

3.7 Lớp Bọc Mã hóa Bên ngoài

Ngay cả khi việc giải mã timelock về mặt toán học là khả thi—một khi chữ ký drand cho vòng bị ràng buộc đã được công bố—chỉ riêng lớp timelock chuẩn đã cho phép một bộ lập chỉ mục giải mã hàng loạt các qub có thể được khám phá. Giao hàng riêng tư đóng kênh đó với một lớp đối xứng bổ sung quanh các byte được mã hóa timelock (Giao thức §13). Giao hàng công khai cố ý bỏ qua lớp bao bọc để các liên kết thông báo, nhúng và khám phá có thể hoạt động mà không cần một mảnh bí mật.

Lớp bọc sử dụng AES-256-GCM, một bộ mã hóa được xác thực được chuẩn hóa bởi NIST, với một khóa K 256-bit mới được tạo cho mỗi qub bởi CSPRNG của trình duyệt của bạn. K được ràng buộc với qub_id của qub dưới dạng dữ liệu bổ sung được xác thực, vì vậy một khóa từ một qub không thể được tái sử dụng để giải mã một qub khác.

K không bao giờ đến được máy chủ của chúng tôi trong luồng trình duyệt riêng tư mặc định. Nó được mã hóa vào phần mảnh URL của liên kết chia sẻ (https://qub.social/c/<tx_id>#<base64url(K)>). Trình duyệt không gửi các đoạn URL đến máy chủ—RFC 3986 đặt đoạn đó bên ngoài yêu cầu—vì vậy qub.social, các cổng lưu trữ, CDN và việc giám sát yêu cầu đều không biết K trong luồng đó. Các dữ liệu đã lưu OuterWrapper là CBOR cấu trúc có thể nhận biết, nhưng trường văn bản mã hóa được xác thực của nó ẩn phần bên trong SealedQub cấu trúc và không thể mở mà không có K.

Hậu quả ròng:

Điểm cuối phía máy chủ /api/v1/seal của Worker (được sử dụng bởi các tác nhân AI và những người gọi API khác) yêu cầu người gọi tạo K bằng một CSPRNG, giữ lại nó cục bộ, và cung cấp nó dưới dạng wrapper_key_b64url. Worker tất yếu thấy cả văn bản gốc và K trong bộ nhớ trên con đường được tin cậy rõ ràng này, nhưng không lưu giữ cái nào. Một Idempotency-Key bắt buộc ngăn một phản hồi bị mất tạo ra một qub bị tính phí thứ hai, trong khi K do người gọi giữ lại có thể được kết hợp với URL không có fragment được phát lại. Điều này khác với con đường trình duyệt mặc định, nơi K không bao giờ đến Worker trừ khi người tạo bật khôi phục một cách rõ ràng.

4. Truyền tải và Biên

4.1 TLS

Lưu lượng trình duyệt đến qub được phục vụ qua HTTPS tại điểm biên Cloudflare. Các phản hồi thiết lập HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Phiên bản TLS và bộ mã hóa chính xác được thương lượng được điều chỉnh bởi cấu hình edge đang hoạt động thay vì được xác nhận bởi mã ứng dụng. Chúng tôi không phơi bày một máy chủ gốc có thể truy cập riêng lẻ.

4.2 Bảo mật Nội dung

Máy khách được biên dịch được phục vụ với các tiêu đề loại nội dung và bộ nhớ đệm nghiêm ngặt. Vỏ SPA là một nguồn gốc duy nhất. Chúng tôi không nhúng các tập lệnh bên thứ ba cho phân tích hoặc quảng cáo. Hai điểm tiếp xúc bên thứ ba trong sản phẩm đều được giới hạn hẹp: luồng mua rời khỏi SPA hoàn toàn với một chuyển hướng toàn trang đến thanh toán do Stripe lưu trữ (https://checkout.stripe.com/…) — giao diện người dùng của Stripe không bao giờ thực thi trong nguồn gốc của chúng tôi và chúng tôi không bao giờ thấy dữ liệu thẻ — và luồng niêm phong tải tiện ích Turnstile của Cloudflare, một lựa chọn thay thế CAPTCHA bảo vệ quyền riêng tư mà Cloudflare hiển thị bên trong iframe sandbox của chính nó. Không bên nào có thể đọc phần còn lại của trang.

Cái qub nhúng iframe (phục vụ từ qub.social/embed/{tx_id} và được tải lên các trang web của bên thứ ba bởi embed.js) mang theo chính sách Bảo mật Nội dung của riêng nó. Nó connect-src danh sách cho phép là 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh, và https://drand.cloudflare.com. Iframe chạy với sandbox="allow-scripts allow-top-navigation-by-user-activation" (không allow-same-origin): trang chủ không thể đọc DOM của nó, và nó không thể điều hướng máy chủ ngoại trừ sau một hành động của người dùng.

4.3 CORS và Phạm vi Fetch

Máy khách trình duyệt thực hiện các yêu cầu fetch chỉ đến:

Các điểm đến của embed được thực thi bởi CSP của nó. Các điểm đến dự kiến của SPA chính được cố định trong mã và cấu hình và được kiểm tra thông qua trình duyệt và kiểm tra tích hợp; Subresource Integrity không phải là một cơ chế kiểm soát điểm đến mạng.

Embed lấy các byte đã lưu trữ thông qua các nguồn qub/storage được cho phép, mở các payload riêng tư trong trình duyệt bằng K từ đoạn URL của nó, và lấy chữ ký round vào thời điểm tiết lộ từ hai nguồn drand được cho phép. SPA chính sử dụng bộ dự phòng bốn endpoint được đặt trong config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh, và api3.drand.sh) vì sự gián đoạn tại một đầu cuối không chặn việc hiển thị. CSP nhúng từ chối các kết nối bên ngoài danh sách rõ ràng của nó.

5. Hạ tầng Phía Máy chủ

5.1 Biên Không Máy chủ

API của chúng tôi chạy hoàn toàn trên một thời gian chạy không máy chủ được quản lý tại biên. Không có VM, không có container và không có quy trình máy chủ liên tục mà chúng tôi quản trị. Điều này giảm đáng kể bề mặt tấn công mà chúng tôi chịu trách nhiệm: chúng tôi không chạy một hệ điều hành, một máy chủ web, hoặc một thời gian chạy ứng dụng mà chúng tôi phải vá.

Một middleware public-CORS riêng biệt được áp dụng Access-Control-Allow-Origin: * đến tập hợp đường dẫn đã triển khai sau: /embed.js, /embed/v1.js, mọi thứ dưới /embed/; /api/v1/telemetry; /api/v1/openapi.json; mọi thứ dưới /api/v1/qub/ (bao gồm bytes, metadata, proof, engagement, notify, và các tuyến phụ push); tất cả mọi thứ dưới /api/v1/log/; xử lý tra cứu công khai theo /api/v1/handle/; và avatar công khai đọc dưới /api/v1/identity/avatar/. Giấy phép trước chuyến bay của nó GET, POST, và OPTIONS với Content-Type tiêu đề yêu cầu. Bề mặt dựa trên tiền tố này rộng hơn chỉ các cuộc gọi mà embed hiện tại thực hiện, vì vậy mọi bộ xử lý bên dưới các tiền tố đó phải tiếp tục thực hiện các kiểm tra về xác thực, xác minh quyền truy cập, giới hạn tốc độ và kiểm soát lạm dụng của riêng nó. Các đường dẫn API khác vẫn giữ chính sách CORS hạn chế qub.social.

5.2 Lưu trữ

Luồng tin nhắn trình duyệt mặc định không lưu bản văn bản thuần trên hạ tầng qub. Builder /api/v1/seal xử lý văn bản thuần túy và K trong bộ nhớ nhưng không lưu trữ cả hai. Giai đoạn Pact cần thiết lưu trữ pact có cấu trúc đã ký cho đến khi nó được đồng ký, thu hồi hoặc hết hạn. Khôi phục tùy chọn lưu trữ một khả năng giao hàng (liên kết chứa toàn bộ đoạn) để có thể khôi phục sau này. Do đó, chúng tôi không mô tả toàn bộ tầng lưu trữ là “chỉ siêu dữ liệu”.

5.3 Bí mật

Các bí mật (ví ký, token nhà cung cấp và khóa HMAC) được cung cấp thông qua ràng buộc bí mật/môi trường của nền tảng thay vì qua quản lý mã nguồn. Các thành phần chạy thời gian thực chỉ nhận các ràng buộc mà chúng cần. Các quy trình xoay vòng và chồng chéo là riêng biệt theo từng thành phần; chúng tôi không tuyên bố có một cơ chế xoay vòng tự động hoặc được kiểm toán chung duy nhất.

5.4 Ghi nhật ký và Đo lường từ xa

Các nhật ký JSON có cấu trúc được viết trên mọi yêu cầu API với một ID tương quan hiển thị trong tiêu đề phản hồi X-Request-Id. Đo lường từ xa của máy khách là ẩn danh — không có định danh thiết bị, không có địa chỉ IP, không có bản xem trước nội dung. Các sự kiện được đệm trong bộ nhớ và được xả trên cơ sở nỗ lực tốt nhất; một lần xả thất bại bị loại bỏ, không được thử lại. Đo lường từ xa được thiết kế để có thể vô hiệu hóa ở lớp mạng mà không ảnh hưởng đến sản phẩm.

6. Xác thực

6.1 Đăng nhập Magic-Link

Đăng nhập sử dụng một mã thông báo chỉ dùng một lần, được ký HMAC gửi đến hộp thư email của bạn. Liên kết có hiệu lực trong 15 phút và việc đổi mã được yêu cầu một cách nguyên tử nên việc sử dụng đồng thời hoặc sử dụng lại sẽ thất bại. Khi thành công, trình duyệt sẽ nhận được một mã không rõ. __Host-qub_session bánh quy với Secure, HttpOnly, SameSite=Strict, và Path=/ thuộc tính.

Các phiên có giới hạn không hoạt động là 30 ngày và giới hạn tuyệt đối là 90 ngày, xoay vòng sau 24 giờ, và chỉ chấp nhận thế hệ ngay trước đó cho thời gian ân hạn phản hồi mất 120 giây. Các thay đổi nhạy cảm của tài khoản yêu cầu xác thực trong vòng 10 phút trước đó. Bí mật ký HMAC là ràng buộc nền tảng; việc đọc chỉ có siêu dữ liệu không tự nó tạo ra một token hợp lệ.

6.2 Khóa API (Cấp Nhà phát triển)

Các khóa API nhà phát triển sử dụng tiền tố qub_sk_ để dễ nhận diện và có thể grep. Mỗi khóa:

Các điểm cuối quản lý khóa của quản trị viên được kiểm soát phía sau một thông tin xác thực quản trị viên riêng biệt.

6.3 Xác nhận Email (Ký Quyền Tác giả)

Việc ràng buộc một địa chỉ email với một khóa ký yêu cầu:

  1. Sở hữu khóa ký riêng (bạn ký một thử thách)
  2. Sở hữu hộp thư email (bạn nhập một mã 6 chữ số được gửi qua email)

Một mình một trong hai là không đủ. Việc thu hồi là một bản ghi đã ký trên chính tài khoản của bạn và có hiệu lực ngay lập tức; các trình xem lấy xác nhận thấy trạng thái đã thu hồi và hiển thị tương ứng.

7. Thanh toán

Việc nhập và xử lý thẻ diễn ra trong thanh toán do Stripe lưu trữ. Chúng tôi không bao giờ nhận được số thẻ, ngày hết hạn hoặc CVC. Chúng tôi lưu trữ các định danh khách hàng và đăng ký của Stripe, trạng thái đăng ký và dữ liệu kỳ hạn trên các hồ sơ quyền/API-key để có thể đối chiếu quyền truy cập, gia hạn, đo lường, hủy bỏ và hoàn tiền. Các tuyên bố về quyền riêng tư và bảo mật của Stripe điều chỉnh việc xử lý dữ liệu thanh toán của họ.

Điểm cuối niêm phong kiểm tra chéo bản ghi quyền đối với định danh thiết bị và, đối với người dùng đã đăng nhập, đối với danh tính liên kết. Một quyền không thể được tái sử dụng trên các thiết bị mà không có người dùng rõ ràng khôi phục nó qua đăng nhập magic-link.

8. Khả năng chống Lạm dụng

8.1 Phát hiện Bot

Luồng niêm phong được kiểm soát bởi một lựa chọn thay thế CAPTCHA bảo vệ quyền riêng tư không sử dụng cookie để theo dõi và không lập dấu vân tay để quảng cáo. Một thử thách thất bại bị từ chối bởi Worker biên của chúng tôi trước khi bất kỳ xử lý phía niêm phong nào diễn ra.

8.2 Giới hạn Tốc độ

Giới hạn tốc độ được thực thi ở nhiều lớp:

Các bộ đếm và các yêu cầu nguyên tử được phân phối trên KV, Durable Objects và các ràng buộc giới hạn tần suất của nền tảng theo yêu cầu nhất quán của điểm cuối. Các yêu cầu bị giới hạn tần suất sẽ trả về 429; các điểm cuối có thể tính cửa sổ thử lại bao gồm Retry-After.

8.3 Kiểm duyệt Nội dung

Đường tải lên trình duyệt mặc định không thể quét nội dung thân bài: nó chỉ nhận vật phẩm được đóng dấu bởi client. Trình Xây dựng /api/v1/seal tuyến đường thấy văn bản rõ ràng tạm thời, và giai đoạn lập kế hoạch giữ các điều khoản có cấu trúc cho đến khi hoàn tất, nhưng những ngoại lệ tin cậy đó không biến đường tải lên mù byte chung thành một trình quét nội dung. Điều tiết vận hành là một danh sách từ chối tại lớp người xem: một qub bị từ chối trong danh sách đen sẽ bị trình xem của chúng tôi từ chối bất kể liệu payload đã lưu có còn khả dụng hay không. Việc đưa vào danh sách đen không rút lại các byte bền, các mục nhật ký minh bạch hoặc dữ liệu mạng vĩnh viễn đã được công bố.

Các báo cáo lạm dụng được giới hạn tốc độ sử dụng một giá trị băm một chiều của IP của người báo cáo; chúng tôi không lưu trữ IP rõ ràng cho mục đích này.

9. Chuỗi Cung ứng và Tính toàn vẹn Xây dựng

9.1 Ghim Bộ Công cụ

Phiên bản trình biên dịch và thời gian chạy được cố định trong cấu hình kho lưu trữ và các phụ thuộc được giải quyết thông qua các tệp khóa đã cam kết. CI kiểm tra tính mới của tệp được tạo ra và các bất biến nhạy cảm với khả năng tái tạo. Chúng tôi không đưa ra khẳng định mạnh mẽ rằng mọi lần xây dựng sạch đều giống hệt từng bit trên tất cả các máy được hỗ trợ.

9.2 Lint và Phân tích Tĩnh

Khu vực làm việc cho phép các nhóm lint nghiêm ngặt nhất của chúng tôi ở mức deny. CI coi mọi cảnh báo — bao gồm các cảnh báo liên kết tài liệu — là một lỗi xây dựng. Đây là cố ý: chúng tôi sử dụng độ nghiêm ngặt của lint như một dây bẫy cho các hồi quy tinh tế.

9.3 Cổng CI

Quy trình làm việc CI bao gồm định dạng và kiểm tra strict lint; kiểm tra Rust, WASM/trình duyệt, Worker, nhúng và API; kiểm tra kiểu; độ bao phủ mã; kiểm tra đột biến/bất biến; phân tích tĩnh phụ thuộc và quy trình làm việc; kiểm tra khóa i18n, độ bao phủ, sai lệch và điểm mã có hại; làm mới tài liệu/API/cơ sở kiến thức được tạo tự động; kiểm tra tồn kho tài liệu và liên kết nội bộ; ngân sách bảng kiểu và gói; và xác thực OpenAPI. Một số công việc đột biến tốn kém được lên lịch thay vì chạy trên mỗi lần đẩy mã.

Một yêu cầu duy nhất ci roll-up vẫn giữ màu đỏ nếu bất kỳ công việc bắt buộc nào thất bại. Các workflow nhánh được bảo vệ và triển khai sử dụng kết quả đó thay vì nhân bản một cổng bảo mật nhỏ hơn.

9.4 Kiểm thử Đột biến

Một công việc hàng tuần chạy kiểm thử đột biến đối với các mô-đun thuần túy trọng yếu về bảo mật: băm, CBOR chuẩn tắc, niêm phong, mở khóa, các newtype định dạng truyền dẫn, các trình xác thực kiểu giao thức, và không gian tên tên người dùng. Kiểm thử đột biến trả lời "bộ kiểm thử của chúng tôi có bắt được mã sai một cách tinh tế không?" — nếu một triển khai bị đột biến vẫn vượt qua tất cả các bài kiểm thử, chúng tôi biết chúng tôi có một khoảng trống về độ phủ kiểm thử và giải quyết nó.

9.5 Git Hooks

Các hook cục bộ (pre-commit, pre-push) phản ánh các cổng CI để các hồi quy được bắt trước khi chúng rời khỏi máy của nhà phát triển. Các hook được cài đặt qua một tập lệnh kho lưu trữ; chúng không được bỏ qua trong quy trình làm việc của chúng tôi và CI là cổng có thẩm quyền nếu chúng bị bỏ qua.

10. Kiểm thử

Mã trọng yếu về bảo mật mang ba loại bài kiểm thử:

11. Vệ sinh Nhánh và Phát hành

Các nhánh tính năng tiến lên staging chỉ thông qua một yêu cầu kéo Gate 1: bắt buộc ci xanh, không có yêu cầu thay đổi chưa giải quyết, không có xung đột hợp nhất, và một cây đã được xem xét sạch; việc hợp nhất là gộp và xóa. main chỉ tiến tới qua Cổng 2 staging → main pull request và giữ nguyên nguồn gốc với một commit hợp nhất. Việc đẩy trực tiếp lên nhánh không phải là quy trình phát hành.

Việc triển khai trên môi trường thử nghiệm và sản xuất được kích hoạt từ môi trường được bảo vệ tương ứng staging và main các nhánh trạng thái sau CI. Mã pull-request và thông tin đăng nhập fork không nhận được bí mật triển khai.

Các bí mật được sử dụng trong các quy trình triển khai được giới hạn trong môi trường triển khai bởi nền tảng CI của chúng tôi. Chúng không có sẵn cho các quy trình pull-request từ các fork.

12. Tiết lộ Phối hợp

Nếu bạn tin rằng bạn đã tìm thấy một lỗ hổng bảo mật trong qub, chúng tôi muốn nghe về nó nhanh chóng và chúng tôi cam kết xử lý báo cáo một cách chuyên nghiệp.

Chúng tôi xác nhận nhận trong vòng ba ngày làm việc và giữ cho bạn được thông báo khi chúng tôi điều tra. Với sự đồng ý của bạn, chúng tôi ghi nhận người báo cáo trong ghi chú phát hành.

12.1 Bến đỗ An toàn

Nếu nghiên cứu của bạn tuân theo các quy tắc trên (điều tra thiện chí, không gây hại cho người dùng khác hoặc dịch vụ, khung thời gian tiết lộ hợp lý), chúng tôi sẽ không theo đuổi hành động pháp lý chống lại bạn, và chúng tôi sẽ không yêu cầu cơ quan thực thi pháp luật làm điều đó. Chúng tôi coi công việc của bạn là thử nghiệm được ủy quyền và chúng tôi thà bạn tìm ra lỗi hơn là người khác.

Bến đỗ An toàn này áp dụng cho:

Nó không áp dụng cho kỹ thuật xã hội đối với các thành viên nhóm qub, các bài kiểm tra từ chối dịch vụ, hoặc truy cập dữ liệu của người dùng khác vượt quá những gì cần thiết để chứng minh vấn đề. Nếu bạn không chắc liệu điều gì đó có rơi vào Bến đỗ An toàn hay không, hãy hỏi trước bằng cùng tiền tố tiêu đề [SECURITY].

13. Giới hạn Trung thực

Bảo mật là một thực hành, không phải một trạng thái. Một số giới hạn đáng được nêu trực tiếp:

14. Thay đổi đối với Trang này

Các thay đổi trọng yếu được lưu ý bằng cách cập nhật ngày hiệu lực ở đầu. Khi một thay đổi phản ánh một cải tiến bảo mật cụ thể, chúng tôi mô tả ngắn gọn nó trong nhật ký thay đổi công khai. Khi một thay đổi phản ánh một làm rõ chính sách, chúng tôi mô tả những gì đã thay đổi và tại sao.

Đối với các câu hỏi về bất cứ điều gì trên trang này, gửi email support@qub.social với tiền tố tiêu đề [SECURITY].

15. Nhật ký thay đổi

Phiên bản Ngày có hiệu lực Tóm tắt
1.1 23 tháng 9 năm 2026 Đã đối chiếu các yêu cầu mật mã, chế độ giao nhận, lưu trữ, CSP, phiên làm việc, khóa API, thanh toán, CI và quy trình phát hành với hệ thống đã triển khai.
1,0 2 tháng 5 năm 2026 Xuất bản ban đầu.