Có nên khắc phục lỗ hổng trong các cam kết cũ?

Một trong những dự án của tôi trên GitHub đã nhận được cảnh báo về lỗ hổng, trong trường hợp này là mức độ nghiêm trọng vừa phải.

Lỗ hổng đã được phát hiện trong sự phụ thuộc của một phiên bản cũ của mã. Các phiên bản hiện tại không sử dụng phụ thuộc này nữa. Tuy nhiên, các cam kết cũ có thể có khả năng được kiểm tra và chạy, và mở ứng dụng để khai thác lỗ hổng.

Từ góc độ công nghệ phần mềm, có nên quay lại và thay đổi các cam kết cũ, tức là cập nhật sự phụ thuộc hiện không được sử dụng lên phiên bản mới hơn có chứa bản sửa lỗi cho lỗ hổng không? Hoặc tốt hơn để giữ cho lịch sử cam kết nguyên vẹn?

Tôi thấy hai lựa chọn khả thi ở đây.

Đầu tiên, phát hành một phiên bản vá của phiên bản có vấn đề. Ví dụ: nếu phiên bản có vấn đề là phiên bản 3.3 và bạn đang ở phiên bản 5.1, bạn có thể phát hành phiên bản 3.3.1 sẽ giải quyết lỗ hổng. Điều này sẽ cho phép người dùng không thể nâng cấp lên các phiên bản chính (vì bất kỳ lý do nào) để có được bản sửa lỗi cho lỗ hổng.

Thứ hai, không làm gì cả. Đây là phiên bản cũ của phần mềm và bạn có các phiên bản mới hơn được duy trì mà không có lỗ hổng. Người dùng quan tâm đến bảo mật nên chạy phiên bản mới hơn.

Lựa chọn nào là tốt nhất? Nó phụ thuộc. Tuy nhiên, quay lại và sửa đổi các cam kết cũ (viết lại lịch sử) không có nhiều ý nghĩa. Và đối với một số người dùng (đặc biệt là trong một môi trường quy định) sẽ có nhiều vấn đề với điều này. Để sử dụng rộng rãi phần mềm của bạn, nên tránh viết lại lịch sử.

Xem xét:

• Lỗ hổng nghiêm trọng đến mức nào?
• Làm thế nào rộng rãi là phiên bản của lỗ hổng?
• Bạn có khả năng tiếp tục hỗ trợ các phiên bản cũ - bạn sẽ quản lý điều này như một tiền lệ?

Thông thường một hệ thống kiểm soát phiên bản được sử dụng để ghi lại lịch sử; cung cấp một cái nhìn chính xác về trạng thái của mã tại một thời điểm cụ thể. Kết quả của việc kiểm tra và xây dựng một phiên bản cũ phải là phiên bản đó, lỗi và tất cả. Một số hệ thống cung cấp các bản dựng có thể lặp lại : có thể tạo ra một bản nhị phân giống hệt với bản dựng cũ.

Hầu hết các hệ thống kiểm soát phiên bản không cho phép viết lại lịch sử, ngoại trừ các trường hợp khắc nghiệt như xóa thông tin có thể gây ra trách nhiệm nếu được đăng nhập. Thật bất thường và một chút "dị giáo" mà git cho phép bạn làm điều này.

Các tài liệu thừa nhận có những rủi ro để viết lại lịch sử .

Hơn nữa, đây là một hệ thống kiểm soát phiên bản phân tán - viết lại nó không ảnh hưởng đến bất kỳ kho lưu trữ nào đã được nhân bản!

Tôi sẽ đề nghị không bao giờ làm điều này trừ khi nó loại bỏ thứ gì đó đã được cam kết gần đây cần được giữ bí mật - dữ liệu cá nhân, khóa mã hóa, loại đó.

Dường như ngay cả câu trả lời hiện được chấp nhận cũng không thực sự giải quyết phần câu hỏi của bạn làm thế nào để tránh việc ai đó vô tình truy cập vào một cam kết cũ, sử dụng trạng thái cũ của cơ sở mã trong một nhánh mới và do đó lại giới thiệu một lỗ hổng cũ.

IMHO cách duy nhất đúng để địa chỉ này là:

• bằng cách ghi lại bất kỳ sửa lỗi nào cũng như sửa lỗi dễ bị tổn thương trong tài liệu "ghi chú phát hành" (hoặc "nhật ký thay đổi") của hệ thống

• bằng cách đảm bảo tất cả các nhà phát triển truy cập các phiên bản mã cũ hơn đảm bảo họ đọc ghi chú phát hành, kiểm tra xem vấn đề nào đã được giải quyết trong phiên bản mã xuất hiện sau phiên bản mã họ sẽ sử dụng

Khi sử dụng lại một phiên bản cũ hơn hoặc phân nhánh từ một phiên bản cũ hơn của cơ sở mã, rõ ràng là trách nhiệm của các nhà phát triển không làm điều này một cách mù quáng. Rõ ràng là họ phải kiểm tra chéo các lỗi và lỗ hổng đã được sửa, vì không giới thiệu lại chúng. Tuy nhiên, nhật ký VCS không thực sự là một nơi tốt để tìm loại thông tin này, bởi vì thông thường có tất cả các loại thay đổi được đề cập, ở mức độ trừu tượng quá thấp.

Tuy nhiên, ghi chú phát hành phải chứa phần "tính năng mới" cũng như phần "giải quyết vấn đề". Và sau này nên là nơi đầu tiên để kiểm tra trước khi phân nhánh từ một phiên bản cũ hơn.

Nói 3.5 là dễ bị tổn thương, nhưng 3.6 thì không. Bạn có thể sản xuất 3.5.1 mà không có lỗ hổng. Nhưng đó là công việc và không hữu ích lắm, bởi vì mọi người cập nhật phiên bản của họ hoặc họ không, vì vậy không có ai sẽ sử dụng 3.5.1.