Nhãn Verified trên GitHub vẫn còn sau khi khóa ký bị thu hồi

Theo hướng dẫn xác minh chữ ký của GitHub, một commit đã được xác minh vẫn giữ nhãn Verified nếu khóa ký về sau bị thu hồi hoặc hết hạn. GitHub lưu hồ sơ xác minh khi commit được đẩy lên và không tự đổi trạng thái cũ theo tình trạng mới của khóa. Trước khi hợp nhất hoặc dùng mã nguồn, cần xem thời điểm GitHub xác minh, đối chiếu khóa với người được phép ký, rồi kiểm tra đúng commit trên máy.

Với một commit đã tải về, có thể bắt đầu bằng lệnh git show --show-signature <SHA>, thay <SHA> bằng mã định danh của commit cần đánh giá. Kết quả chữ ký cho biết dữ liệu commit có khớp với khóa dùng để ký hay không; việc người giữ khóa còn được dự án tin cậy là câu hỏi riêng. Vì vậy, một dòng báo chữ ký hợp lệ chưa đủ để quyết định nhận thay đổi.

Thời điểm Verified nói lên điều gì?

Verified ghi nhận kết quả xác minh của GitHub tại một thời điểm cụ thể. Đưa con trỏ lên nhãn này trên trang commit sẽ thấy thời điểm xác minh; dữ liệu commit qua REST API cũng có trường verified_at. Mốc đó là lúc GitHub hoàn tất xác minh, không nhất thiết là lúc commit được tạo hoặc lúc người ký còn quyền đóng góp cho dự án.

Hồ sơ xác minh được giữ trong mạng lưới của kho lưu trữ. Nếu cùng một commit xuất hiện lại ở kho đó hoặc một fork liên quan, GitHub dùng lại hồ sơ đã có thay vì xác minh lại chữ ký. Với commit có từ trước cơ chế lưu hồ sơ, hồ sơ sẽ được tạo khi chữ ký của nó được GitHub xác minh lần tiếp theo. Bởi vậy, khi xem một commit cũ, hãy ghi lại cả SHA và verified_at: hai thông tin này xác định đối tượng đang xét và thời điểm kết quả trên giao diện được ghi nhận.

Việc thu hồi khóa có thể diễn ra sau thời điểm ấy, trong khi nhãn của commit cũ vẫn giữ nguyên. Khoảng cách giữa hai thời điểm mới là điều cần làm rõ trước khi dựa vào chữ ký để đánh giá nguồn gốc thay đổi. Nhãn không tự cho biết lý do thu hồi khóa hay quyết định thu hồi có áp dụng cho những commit được ký trước đó hay không.

Khóa nào đã ký và ai được phép dùng khóa đó?

Chữ ký gắn dữ liệu commit với một khóa ký, còn quyền đại diện cho dự án phải được xác định bằng thông tin ngoài commit. GitHub hỗ trợ GPG, SSH và S/MIME; khóa GPG hoặc SSH dùng để xác minh được gắn với tài khoản theo cách khác với chứng chỉ S/MIME. Trước khi đối chiếu danh tính, hãy nhận diện loại chữ ký và khóa thực sự được công cụ xác minh sử dụng.

Tên tác giả trong commit, tên người ký và người đã đẩy commit lên kho có thể là những thông tin khác nhau. Một tên hoặc địa chỉ email trông quen thuộc cũng không thay thế được việc đối chiếu dấu vân tay khóa với danh sách khóa do dự án chấp nhận. Nếu dự án công bố khóa được phép ký bản phát hành hoặc nhánh được bảo vệ, hãy dùng quy định đó để xác định liệu người giữ khóa có thẩm quyền đối với thay đổi đang xét.

Khi khóa đã bị thu hồi, cần tìm thời điểm và phạm vi của quyết định thu hồi từ người quản lý khóa hoặc dự án. Chẳng hạn, nếu khóa bị thu hồi vì nghi đã lộ, chữ ký trên commit cũ có thể cần được xem xét khác với trường hợp khóa chỉ ngừng được sử dụng theo kế hoạch; đây là hai tình huống giả định, không phải kết luận có thể rút ra từ nhãn Verified. Nếu chưa xác định được người có quyền ký hoặc phạm vi thu hồi, chưa nên coi chữ ký là bằng chứng đủ về quyền gửi mã.

Xác minh đúng commit bằng Git tại máy

Hãy dùng SHA của commit cần nhận, vì tên nhánh có thể trỏ sang commit khác sau khi bạn mở trang pull request. Trong tài liệu định dạng chữ ký Git, chữ ký commit nằm ở trường gpgsig của đối tượng commit; Git nêu các lệnh git verify-commit <SHA> và git show --show-signature <SHA> để xác minh. Chạy lệnh trong kho đã tải đúng đối tượng đó và đọc cả cảnh báo đi kèm, không chỉ dòng thông báo chữ ký tốt.

Để thấy trạng thái, dấu vân tay khóa và tên người ký trên một dòng, có thể chạy git log -1 --format='%H %G? %GF %GS' <SHA>. Theo bảng ký hiệu của Git, %G? cho biết trạng thái chữ ký, %GF là dấu vân tay khóa và %GS là tên người ký; G nghĩa là chữ ký hợp lệ, R là chữ ký hợp lệ từ khóa đã bị thu hồi, Y là chữ ký hợp lệ từ khóa hết hạn, còn E cho biết không thể kiểm tra, chẳng hạn vì thiếu khóa. Đây là kết quả từ khóa và cấu hình sẵn có trên máy, nên phải xem thông báo chi tiết trước khi diễn giải một ký hiệu đơn lẻ.

Nếu máy thiếu khóa công khai, hãy lấy khóa từ kênh mà dự án chỉ định rồi đối chiếu dấu vân tay trước khi xác minh lại. Không thể kiểm tra vì thiếu khóa khác với việc chữ ký không khớp dữ liệu commit. Ngược lại, thông báo chữ ký tốt nhưng khóa chưa được xác lập là đáng tin vẫn đòi hỏi bước đối chiếu người ký; kiểm tra mật mã không tự cấp quyền cho người giữ khóa.

Kết quả tại máy có thể khác nhãn GitHub vì hai phép xem xét dùng thông tin ở những thời điểm khác nhau: GitHub giữ hồ sơ xác minh trước đó, còn Git dùng trạng thái khóa mà môi trường cục bộ biết khi chạy lệnh. Với chữ ký SSH hoặc S/MIME, cách chuẩn bị khóa tin cậy tại máy cũng khác GPG. Nếu công cụ chưa được cấu hình để xác minh loại chữ ký của commit, hãy hoàn tất cấu hình trước khi coi thông báo lỗi là nhận định về chính commit.

Ghép các kết quả trước khi hợp nhất

Quyết định nhận commit cần dựa trên cùng một đối tượng ở cả ba lớp: SHA và verified_at trên GitHub, khóa cùng chủ thể được phép ký, và kết quả xác minh cục bộ. Nếu chữ ký khớp nhưng khóa không thuộc người được dự án cho phép, bằng chứng mật mã không giải quyết được câu hỏi về quyền gửi thay đổi. Nếu khóa đã bị thu hồi, hãy làm rõ quyết định thu hồi có ảnh hưởng đến commit được ký trước đó hay không.

Khi thiếu khóa công khai hoặc thông tin ủy quyền, có thể tạm dừng hợp nhất để người quản lý dự án xác nhận commit cụ thể. Nếu khóa không còn được chấp nhận cho thay đổi đang chờ nhận, người gửi có thể cần tạo commit mới bằng khóa được dự án chấp thuận. Cách xử lý phụ thuộc vào chính sách của dự án và lý do khóa đổi trạng thái, thay vì phụ thuộc riêng vào nhãn còn hiển thị trên giao diện.

Đọc thêm:

• GitHub Copilot đổi cách tính tiền ghế: xóa người dùng giữa kỳ vẫn chưa hết phí
• Gắn nhãn nội dung AI theo Điều 50: watermark máy đọc vẫn chưa đủ
• LINK chỉ cách kính Swift 12–15 km: cuộc giải cứu thất bại vẫn để lại dữ liệu quý