- Bảo trì rsync đang ở trong tình huống cần đến bộ kiểm thử kỹ lưỡng hơn, phân tích độ bao phủ mã, CI đa nền tảng, quét bảo mật và các biện pháp phòng thủ nhiều lớp do vừa gặp làn sóng báo cáo bảo mật tăng vọt vừa vướng tranh cãi về việc dùng AI
- Bộ kiểm thử Python mới thay thế cấu trúc script shell hiện có, nhưng phần thiết kế và kế hoạch kiểm chứng do người bảo trì đảm nhiệm; Claude, Codex và Gemini được dùng theo cách hỗ trợ các công việc lặp lại
- Bản phát hành 3.4.3 là bản ưu tiên các bản vá bảo mật, nhưng đã phát sinh hồi quy ở một số trường hợp sử dụng hợp lệ nhưng khác thường mà các bài kiểm thử hiện có và kiểm thử thủ công không phát hiện ra
- pytest được dùng nhiều ở các dự án khác, nhưng không phù hợp với một số yêu cầu cụ thể của bộ kiểm thử rsync nên đã chọn thiết kế một cách tiếp cận riêng; LLM cần được dùng thận trọng nhưng vẫn được xem là công cụ hữu ích
- Hướng đi tiếp theo đang được quyết định giữa 3.4.4 để giảm bớt hồi quy và 3.5.0 với các thay đổi bảo mật lớn; openrsync hiện thất bại 85 trên 98 bài kiểm thử trong bộ kiểm thử mới
Bùng nổ báo cáo bảo mật và tăng cường phòng thủ
- Người bảo trì rsync gần đây cũng đang trải qua tình trạng bị dồn dập báo cáo bảo mật như nhiều nhà phát triển gói mã nguồn mở khác; trong đó nhiều báo cáo là sản phẩm do AI tạo ra, nhưng cũng có một số phân tích thủ công cẩn trọng và chất lượng cao
- Khi số lượng báo cáo tăng mạnh, rsync rơi vào trạng thái cần một bộ kiểm thử chặt chẽ hơn, phân tích độ bao phủ mã, kiểm thử CI trên nhiều nền tảng hơn, quét chủ động các vấn đề bảo mật và các kỹ thuật phòng thủ nhiều lớp
- Người bảo trì đã nghỉ hưu và muốn dành nhiều thời gian hơn cho việc đi thuyền, nhưng do khối lượng công việc cần làm nên đã sử dụng nhiều công cụ AI và không hối tiếc về lựa chọn đó
Bộ kiểm thử Python và công việc được AI hỗ trợ
- Bộ kiểm thử rsync cũ dựa trên script shell đã được viết lại bằng Python, với cấu trúc mà phần thiết kế cốt lõi và kế hoạch kiểm chứng do chính người bảo trì trực tiếp đảm nhiệm
- Claude được dùng cho các công việc lặp lại, còn Codex và Gemini được dùng để đối chiếu chéo; đây không phải kiểu giao phó đơn giản theo dạng “hãy chuyển bộ kiểm thử sang Python”
- Người bảo trì đã tự rà soát mọi phần, dành nhiều thời gian CI để tinh chỉnh, rồi sau đó chuyển sang cách chạy phần lớn kiểm thử trên nhiều VM cục bộ để giảm thời gian chờ CI
- Dấu
co-authored by claude trong lịch sử commit được xem chỉ phản ánh một phần kết quả của toàn bộ công việc kỹ nghệ phần mềm
Tranh cãi về LLM, lựa chọn pytest và hồi quy của 3.4.3
- Quan điểm được đưa ra là LLM không trở thành công cụ vô dụng chỉ vì ta biết cách nó hoạt động; cần dùng cẩn trọng, nhưng trong môi trường bảo trì kỹ nghệ phần mềm và an ninh CNTT hiện nay, nó vẫn hữu ích
- rsync 3.4.3 là một bản phát hành được cố ý nghiêng về ưu tiên sửa các vấn đề bảo mật, và trong quá trình đó một số trường hợp sử dụng hợp lệ nhưng khác thường đã bị ảnh hưởng bởi thay đổi
- Những trường hợp sử dụng bị ảnh hưởng này không nằm trong bộ kiểm thử rsync hiện có lẫn kiểm thử thủ công, và các hồi quy được báo qua issue và PR trên kho GitHub đang được xử lý lần lượt
- pytest được dùng nhiều ở các dự án khác, nhưng do đánh giá rằng một số việc cần làm trong bộ kiểm thử rsync sẽ rất khó thực hiện bằng pytest nên đã chọn thiết kế một hướng kiểm thử riêng
Bản phát hành tiếp theo và mở rộng kiểm thử bảo mật
- Các báo cáo bảo mật vẫn tiếp tục đổ về và hiện có nhiều công việc liên quan đến CVE đang được tiến hành
- Những nhà phát triển khác có năng lực phát triển hệ thống và kiến thức bảo mật đã tham gia, trong đó có một số người trở nên nổi bật chính vì làn sóng phẫn nộ gần đây
- Lựa chọn tiếp theo hiện nằm giữa 3.4.4 để giảm bớt một phần hồi quy và 3.5.0 với những thay đổi lớn hơn rất nhiều; bản 3.5 sẽ nâng tiêu chuẩn bảo mật của rsync lên đáng kể nhưng cũng là một bản phát hành có quy mô thay đổi lớn
- Để áp dụng nhanh một tập thay đổi lớn cho phần mềm như rsync, cần có một bộ kiểm thử toàn diện, và việc viết lại bộ kiểm thử mới xuất phát từ chính nhu cầu đó
- Bản phát hành 3.5 sẽ bao gồm thêm các bài kiểm thử nhằm xử lý các vấn đề liên quan đến bảo mật
So sánh với openrsync và lời kêu gọi review mã
- Trước xu hướng muốn đóng gói openrsync cho một số nền tảng cụ thể, phản hồi được đưa ra là có thể thử áp dụng bộ kiểm thử rsync mới cho openrsync
- Ví dụ chạy như sau
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- openrsync hiện thất bại 85 trên tổng số 98 bài kiểm thử; nhiều lỗi thất bại là do các tính năng không có trong openrsync, nhưng đây vẫn không phải kết quả khả quan
- Thay vì tiếp tục bộc lộ thêm sự phẫn nộ, có lời đề nghị rằng nên thực sự xem xét đoạn mã đã được công khai và đưa ra những phê bình mang tính xây dựng
1 bình luận
Ý kiến trên Lobste.rs
Đọc đoạn trích thì có cảm giác tác giả muốn đi thuyền buồm nhưng vẫn cảm thấy áp lực phải duy trì dự án, và dường như đã nhìn thấy một giải pháp có thể làm được cả hai nhờ LLM
Việc nghỉ hưu và tận hưởng thuyền buồm mà không sửa lỗi là điều hoàn toàn ổn, và việc không sửa lỗi cho một dự án mã nguồn mở cũng vậy. Chỉ cần công khai và minh bạch về điều đó là được. Theo cách nói ngày xưa, chỉ cần “hoan nghênh patch” là đủ. Điều này lại càng đúng nếu các công ty có nhiều nguồn lực đang phụ thuộc vào dự án đó
Tôi mong sẽ có thêm nhiều maintainer và developer có thể tận hưởng nghỉ hưu và thuyền buồm mà không bị áp lực phải nhận “sự trợ giúp” của LLM trong việc bảo trì mã nguồn mở. Dù vậy, nếu ông ấy muốn thử nghiệm LLM trong dự án rsync thì đó vẫn là lựa chọn của ông ấy. Người khác, bao gồm cả tôi, không đồng ý cũng không sao
Dù vì lý do gì, những người quấy rầy các developer mã nguồn mở dường như quên rằng phần mềm mã nguồn mở miễn phí không phải là sản phẩm mà là một món quà
Những người chỉ đứng ngoài quan sát nếu không thích thì cứ fork. Andrew có thể làm việc với dự án theo cách ông ấy muốn, và những lời bình luận hay ý kiến của chúng ta cũng không phải là điều bắt buộc
Điểm đáng hy vọng là về lâu dài có thể sẽ xuất hiện một người khác tiếp quản việc bảo trì rsync. Tridge trước đây cũng từng bàn giao cho một maintainer mới rồi
Tôi đã nghe một bài trình bày về việc OpenJS Foundation cung cấp tài trợ và hỗ trợ chuyển giao cho một số dự án để chuyển từ mô hình một maintainer duy nhất sang bảo trì theo nhóm, rồi viết bài cho LWN, và bài đó dự kiến sẽ được công bố hôm nay. Những dự án như rsync cần nhiều hỗ trợ kiểu này hơn rất nhiều
Vấn đề bảo mật tạo áp lực rất lớn, mức độ phơi bày cao, và thường lại khá xa rời phần cốt lõi của dự án mà maintainer thực sự hứng thú
Việc bảo trì đi kèm nhiều trách nhiệm và không phải lúc nào cũng vui, nhưng tôi luôn thấy biết ơn khi các maintainer phần mềm tự do và mã nguồn mở còn làm cả những việc đó. Có vẻ như không nhiều người làm được như vậy
Có thể chi phí để đạt được một mục tiêu nào đó là quá cao nếu không có trợ giúp từ LLM, còn khi có LLM thì nó trở thành mức chi phí hợp lý
Theo hướng tích cực, đây là việc một maintainer cân bằng công việc và cuộc sống lành mạnh hơn có thể giảm khối lượng công việc nhờ LLM mà vẫn đạt được mục tiêu mong muốn dễ dàng hơn
Phần bị trích chỉ là một đoạn trong phần mở đầu, và bài này rõ ràng được viết với sự cẩn trọng cùng nhiều sắc thái ngữ cảnh, chứ không phải một bài cơ bản về bảo trì mã nguồn mở
Điều kỳ lạ hơn là nó bỏ qua ngay phần ngữ cảnh đứng trước đoạn trích. Nội dung ở đó là số lượng báo cáo tăng vọt, buộc phải nâng đáng kể tuyến phòng thủ của rsync, cần một bộ test suite kỹ hơn nhiều, phân tích độ bao phủ mã, kiểm thử CI trên nhiều nền tảng hơn, rà soát vấn đề bảo mật và bổ sung các kỹ thuật phòng thủ chiều sâu
Trong trường hợp này tác giả đã nghỉ hưu, nhưng ở các dự án mã nguồn mở khác, những người còn có công việc hay việc riêng khác cũng có thể bị cuốn vào mức khối lượng công việc tăng thêm tương tự. Thành thật mà nói, tôi khá bối rối khi bình luận này được upvote nhiều đến vậy, và nó không tạo cảm giác là một bài viết được viết với thiện chí. Ít nhất nó chỉ khá hơn đôi chút so với kiểu phản hồi hời hợt của người chỉ đọc tiêu đề rồi lao vào bình luận
Tôi không định biện minh hay chấp thuận hành vi quấy rối, nhưng phần biện hộ này đang bỏ sót lý do
Lời giải thích là tác giả đã thiết kế cho kiểu vibe coding, đã rà soát mã sinh ra, thành thạo cả code lẫn chatbot, xử lý vibe coding một cách cẩn trọng, và cố cân bằng giữa bảo mật với hồi quy tính năng. Nghe có vẻ hợp lý, nhưng trên thực tế vẫn đã có hồi quy, và tác giả cũng không đi đến được nguyên nhân vì sao
Ông ấy nói rằng “các công cụ AI mạnh ở những tác vụ đơn giản nên đã giao những việc như vậy cho chúng”, nhưng không phải thế. Chatbot thực ra rất kém trong việc viết lách. Đó mới là điểm cốt lõi, nhưng dường như tác giả thậm chí còn không nhận ra điều đó
Sẽ tốt nếu có thể xác nhận liệu gần đây con số đó có thực sự tăng lên không. Bản thân hồi quy không phải chuyện hiếm, và tôi nghĩ cũng có thể là mọi người đang tìm cớ để công kích Andrew
Tác giả đã thừa nhận rằng ở một số trường hợp sử dụng trong bản phát hành rsync 3.4.3 đã xuất hiện hồi quy, và giải thích rằng ở bản phát hành đó ông ấy cố ý ưu tiên nhiều hơn cho việc sửa các vấn đề bảo mật, nên một số trường hợp sử dụng hợp lệ nhưng hiếm đã bị ảnh hưởng bởi thay đổi
Những trường hợp đó không nằm trong test suite sẵn có của rsync hay trong các bài kiểm thử thủ công mà ông ấy tự thực hiện, hiện ông ấy đang xử lý hồi quy và cảm ơn những người đã báo cáo qua issue hoặc PR trên kho GitHub. Ông ấy cũng xin lỗi nếu trường hợp sử dụng của ai đó bị ảnh hưởng, và nói rằng nếu chấp nhận rủi ro bảo mật thì họ có thể dùng lại bản phát hành trước đó
Tôi đã nghe lặp đi lặp lại suốt khoảng nửa năm nay những câu như “thế giới kỹ nghệ phần mềm đã thay đổi dữ dội chỉ trong vài tháng qua”, “thế giới bảo trì phần mềm giữa cơn lũ an ninh CNTT và báo cáo đã thay đổi hoàn toàn chỉ trong vài tuần qua”, và thật sự thấy mệt mỏi
Nếu nguyên nhân của cơn lũ báo cáo này là LLM, thì việc tìm LLM làm giải pháp có cảm giác là một hướng đi sai đến mức khó tin
Dù vậy, tôi hoàn toàn có thể tin ngay rằng việc duy trì thứ gì đó đang nổi tiếng lúc này hẳn là khủng khiếp. Có lẽ với ông ấy, điều tốt nhất là lùi lại và tận hưởng cuộc nghỉ hưu thực sự, thay vì tiếp tục vắt kiệt quỹ thời gian tính toán vốn đã hạn chế
Nếu đó thật sự là một công cụ hữu ích dù chỉ bằng một nửa những gì người ta tuyên bố, thì bản thân sự hữu ích đó sẽ tự lên tiếng
Tuy vậy, câu chuyện từ một người như Tridgell vẫn đáng để lắng nghe. Và “cơn lũ” báo cáo bảo mật cần được xem trọng. Bất kể ai hay thứ gì đã tìm ra chúng, vấn đề bảo mật vẫn là vấn đề bảo mật. Vì vậy bài này cho cảm giác khác với kiểu công kích nhàm chán thường thấy
Cuối cùng chúng ta có thể rơi vào một vòng xoáy đi xuống với mức độ phụ thuộc vào LLM ngày càng lớn
Vì sao đó lại là hướng đi sai? Ý là sẽ tốt hơn nếu không ai có LLM sao?
Phát triển được LLM hỗ trợ không nhất thiết phải tạo ra “kết quả rác”
Tôi trân trọng việc bài này đã được viết ra và chia sẻ. Đặc biệt, đoạn nói rằng đang cân nhắc giữa việc giảm nhẹ một phần hồi quy bằng 3.4.4 hay chuyển thẳng sang 3.5.0 với thay đổi lớn hơn rất đáng chú ý
Nếu tác giả có đọc, thì ở đây 3.4.4 có vẻ là hướng đi đúng. Trong bối cảnh bản phát hành trước có hồi quy, nếu lập tức chuyển sang bản 3.5.0 lớn hơn thì nhiều người sẽ xem là liều lĩnh. Nếu giúp mọi người hiểu rõ sự khác biệt hơn thì mức độ lo ngại sẽ giảm xuống
Về đoạn nói rằng ban đầu tác giả định làm công khai trên master phần cấu trúc cốt lõi của bộ test mới, nhưng giờ lại nghĩ đó có thể là ý tồi vì nó gây ra sự phẫn nộ, tôi không nghĩ việc giảm tính minh bạch sẽ cải thiện nhận thức hay phản ứng. Cùng lắm chỉ là trì hoãn một đợt phản ứng dữ dội hơn mà thôi
Nói openrsync hãy chạy bộ test rsync mới là không công bằng. samba rsync là giao thức 32 còn openrsync là giao thức 27, và nó cũng không tự nhận là đầy đủ tính năng
Medium với Cloudflare là một tổ hợp kinh khủng không nên trộn vào nhau
https://archive.is/qbyVA
Bảo trì mã nguồn mở là công việc khó được ghi nhận. Tridge đã cố sửa nợ kỹ thuật của bộ test và phản hồi có trách nhiệm trước cơn lũ CVE do LLM phát hiện, nhưng có vẻ đã bị Hyrum's Law đánh trúng. Kế hoạch 3.4.4 là lựa chọn đỡ tệ nhất, và cuối cùng có lẽ vẫn phải tiếp tục đẩy nó đi thôi
Vấn đề này khiến tôi phân vân theo cả hai phía. Một mặt, tôi cho rằng bảo mật chỉ có thể được đảm bảo khi con người trực tiếp viết mã
Vì trong lúc viết mã, họ suy nghĩ về chính đoạn mã đó và phát hiện lỗi sớm hơn. Khi tự viết, tôi làm tốt hơn rất nhiều so với lúc chỉ rà soát mã. Khi review, nhiều thứ cứ thế lọt qua vì tôi đã không suy nghĩ cẩn thận về từng dòng
Mặt khác, bỏ qua sự thật cơ bản là hành vi quấy rối là không thể chấp nhận được, Andrew có quyền vận hành dự án của mình theo cách ông ấy muốn trong thời gian rảnh của mình. Nếu ông ấy muốn dùng LLM thì tôi không đồng ý, nhưng đó là dự án của ông ấy và là quyền quyết định của ông ấy. Nếu tôi không thích thì tôi nên chuyển backup của mình sang restic hoặc borgbackup, hoặc fork rsync
Nói cho rõ, tôi không phản đối vibe coding tự thân nó. Ở công ty, tôi gần như bị ép phải dùng, và với phần lớn công việc hiện nay của tôi là viết glue code nhàm chán, không mới mẻ thì nó cũng tạm ổn. Chỉ là tôi không dùng nó trong thời gian rảnh
rsyncvốn cũng không phải là giải pháp quá phù hợpVì nó không giúp khôi phục khi nội dung file đã bị hỏng. Các công cụ như restic tốt hơn nhiều, và còn lưu cả các phiên bản trước của file để xử lý những trường hợp như vậy. Thực tế, nó còn theo dõi cả việc xóa, nên biết được file nào không còn liên quan nữa
Tôi có kinh nghiệm về bảo mật ứng dụng, có thể chọn ra vài exploit và cũng có thể bắt được chúng trong quá trình review. Nhưng hiện tại tôi không giỏi bằng việc cho các LLM hàng đầu lặp đi lặp lại kiểu “tìm thêm các trường hợp bệnh hoạn hơn nữa”
Tôi đã tìm ra vấn đề trong mã của mình, trong các thư viện tôi dùng, và trong những bản triển khai thay thế của phần mềm phổ biến như vậy mà không cần quá nhiều công sức. Thời gian và sự lì lợm mà con người có thể bỏ ra hoàn toàn không thể so sánh được
Trên toàn bộ tổ chức còn có rất nhiều phần mềm bảo mật được triển khai để phòng ngừa, phát hiện và ứng phó với sự cố. Ở mỗi mảng luôn có lỗ hổng và luôn còn việc phải làm thêm. Tổ chức có thể biết rằng mình không thể hoàn hảo, nhưng vẫn thích chấp nhận việc cải thiện thế trận bảo mật hơn là không có cải thiện nào cả. Sự đánh đổi mà LLM mang lại cũng là một phần của điều đó
Điểm đánh đổi này thay đổi theo ngữ cảnh, nhưng hiếm khi dẫn đến kết luận rằng “mọi dòng mã đều phải được viết bằng tay”
Điều đó cũng áp dụng cho các server như rsync. Như tác giả đã nói, có thể cần những đợt refactor lớn để nó trở nên vững chắc và có khả năng phục hồi hơn. Nếu dùng LLM để refactor theo hướng tách quyền hạn, tạo ra code base đáng tin cậy nhỏ hơn, thì có thể chấp nhận một số bug nằm ngoài phạm vi đó
Tôi không biết bối cảnh cụ thể của rsync, nhưng tôi tin rằng trong giới hạn nguồn lực ít ỏi mà các dự án kiểu này thường có, tác giả đang đưa ra quyết định tốt nhất cho dự án và cho người dùng
Bù lại, rclone có tính song song, nên tận dụng băng thông mạng khả dụng hiệu quả hơn nhiều
Điều đó đặt ra mức trần cho loại vấn đề có thể xảy ra
Mức sàn là các bug và lỗ hổng mà tôi có thể tìm ra, người khác có thể tìm ra, hoặc thứ gì khác có thể tìm ra, ví dụ như LLM
Tình huống một người rà soát mã C do chính mình viết, như rsync chẳng hạn, khó mà gọi là một vị trí tốt trong phổ này. Tôi hoàn toàn không có ý công kích Andrew
Tôi đồng cảm với một maintainer đã nghỉ hưu nhưng vẫn muốn đi thuyền, nhưng tôi không nghĩ bối cảnh đó thay đổi điều gì một cách căn bản
Tridgell không nợ chúng ta bất kỳ công việc nào, và ông ấy có quyền nghỉ hưu rồi đi thuyền. Nếu đó là điều ông ấy muốn thì tôi chúc ông ấy thuận buồm xuôi gió. Tôi cũng đồng cảm với cảm giác trách nhiệm của ông ấy, nhưng nếu đọc kỹ giữa các dòng, có vẻ ông ấy phần nào xem đó là một gánh nặng
Nhưng rsync là phần mềm cốt lõi, và tôi cho rằng người muốn bảo trì nó nên giữ một tiêu chuẩn chất lượng nhất định. Nếu công việc của maintainer không đạt tiêu chuẩn đó thì đó là một sai lầm. Điều đó không có nghĩa họ đáng bị quấy rối. Nói rằng điều gì đó là sai lầm không có nghĩa là người mắc sai lầm đó là người tệ hại, hay là ta không cảm thông với họ
Vậy nên câu hỏi là công việc do công cụ lập trình AI tạo ra có đạt chuẩn hay không. Chuẩn ở đây đại khái là “với chất lượng này thì có vẫn tốt hơn là không có hay không”. Nếu nó cải thiện phần mềm thì cứ tiếp tục; nếu nó làm mọi thứ tệ hơn thì nên dừng lại. Tôi không nói đây là một định nghĩa khéo léo, nhưng tôi nghĩ đó là định nghĩa đúng
Chúng ta không có quyền đòi Tridgell làm thêm việc, nhưng vẫn có chỗ để nói rằng “nếu đúng như vậy thì điều này đang khiến người dùng khổ hơn”
Thành thật mà nói, tôi vẫn chưa có quan điểm hoàn toàn rõ ràng để đánh giá công việc này. Đã có regression, và Tridgell mô tả đó là một trường hợp biên, nhưng nếu không có thêm bối cảnh thì tôi không biết phải cân thế nào giữa tác động của regression trong trường hợp biên đó và giá trị của việc sửa các vấn đề bảo mật tiềm ẩn
Có người sẽ nghĩ đến câu “WITHOUT ANY WARRANTY”, nhưng điều khoản đó không liên quan ở đây. Đó là tuyên bố từ chối trách nhiệm pháp lý, chứ không phải từ chối lòng tự hào nghề nghiệp hay kỳ vọng phi pháp lý rằng người ta nên cố gắng làm tốt nhất có thể. Bình luận này cũng được cung cấp “WITHOUT ANY WARRANTY”, nhưng nếu tôi sai thì dĩ nhiên tôi vẫn có thể bị chỉ trích
Không phải tác giả biến nó thành phần mềm cốt lõi. Nếu bạn hay người khác dùng nó thì trách nhiệm nằm ở người dùng. Nếu phần mềm không hoạt động như mong đợi thì hãy fork hoặc thay thế nó. Điều bạn không thể làm là ép người đó phải làm theo ý bạn
Bối cảnh cho những ai đã bỏ lỡ báo cáo về regression ban đầu: https://github.com/RsyncProject/rsync/issues/929
Báo cáo issue là ảnh chụp màn hình từ mastodon post, và sau đó đã có hơn khoảng 300 bình luận tranh cãi tiếp nối
Đừng giải thích, cứ làm như vẫn làm từ trước đến nay là được. Những người không thích thì vẫn sẽ tiếp tục không thích
Họ đã bắt đầu không thích từ khi mọi người ngừng viết assembly, và sau này cũng sẽ không dừng lại