Cách chặn spam bot AI trong kho lưu trữ GitHub bằng cờ `--author` của Git

 (archestra.ai)
2 điểm bởi GN⁺ 9 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Kho lưu trữ Archestra chứng kiến số lượng đóng góp dựa trên AI tăng lên, kéo theo làn sóng bình luận và PR vô nghĩa khiến thảo luận thực sự bị chìm và gánh nặng bảo trì tăng mạnh
  • Issue treo thưởng $900 là không gian để các cộng tác viên thật thảo luận, nhưng đã phình lên tới 253 bình luận vì bot AI, thậm chí xuất hiện thái độ công kích
  • Issue hỗ trợ x.ai provider nhận tới 27 PR đã đóng nhưng không được merge, và đa số người gửi thậm chí chưa hề kiểm thử
  • Giới hạn prior contributor của GitHub không phân biệt được lập trình viên mới thật sự với bot AI, nên nhóm đã thêm người dùng được phê duyệt vào author của commit trên main bằng Git --author
  • Quy trình onboarding dùng quy tắc AI có trách nhiệm và CAPTCHA, sau đó tạo commit whitelist bằng GitHub Action, ưu tiên chất lượng hơn các chỉ số hoạt động bị thổi phồng

Cách spam bot AI lấn át các kho lưu trữ mã nguồn mở

  • Kho lưu trữ Archestra cho biết trái với đà tăng của các chỉ số đóng góp dựa trên AI mà GitHub công bố, thực tế tại hiện trường là chất lượng đóng góp suy giảm và gánh nặng bảo trì tăng lên
  • Issue treo thưởng $900 từng là nơi các cộng tác viên thật đề xuất kế hoạch, đặt câu hỏi và thử triển khai công việc, nhưng khi bot AI kéo đến thì tổng số đã tăng lên 253 bình luận
  • Các tài khoản AI để lại những kế hoạch triển khai vô nghĩa, thậm chí tỏ thái độ công kích với maintainer, làm ô nhiễm thảo luận
  • Các thành viên theo dõi kho liên tục nhận thông báo cho từng bình luận AI, còn các cuộc trao đổi của những cộng tác viên thật như @ethanwater, @developerfred, @Geetk172 thì bị chìm nghỉm
  • Issue hỗ trợ x.ai provider nhận 27 pull request đã đóng nhưng không được merge, và phần lớn trong số đó người gửi còn chưa kiểm thử
  • Một thành viên trong nhóm phải dành nửa ngày mỗi tuần chỉ để dọn dẹp các PR chưa được test và các issue mang tính ảo giác; nếu lơ là, kho lưu trữ sẽ nhanh chóng trở thành nơi thiếu thân thiện với cộng tác viên thật

Cách tiếp cận whitelist để vượt qua giới hạn của GitHub

  • Giới hạn của phản ứng ban đầu

    • Archestra trước tiên đã tạo một bot nhỏ tên là London-Cat để tính điểm uy tín của cộng tác viên
    • London-Cat tính uy tín dựa trên các PR đã được merge và một vài tín hiệu khác, và có ích trong việc nhận diện cộng tác viên như ví dụ này
    • Cách này đã thất bại trong việc ngăn spam
    • Bước tiếp theo là AI sheriff, nhưng như ví dụ này cho thấy, nó còn đóng nhầm cả PR thật

  • Chặn hoạt động không qua onboarding

    • Khi các bình luận và đề xuất AI vô nghĩa tiếp tục xuất hiện, các cộng tác viên thật dần rời đi, buộc nhóm phải xem xét lại cả cách dùng bounty để thu hút đóng góp lẫn cách giao bài test cho ứng viên tuyển dụng
    • Archestra tăng cường biện pháp để biến kho lưu trữ thành nơi thoải mái và an toàn cho cộng tác viên thật, người dùng AI có trách nhiệm, người mới bắt đầu và kỹ sư dày dạn kinh nghiệm
    • Người dùng chưa qua onboarding nay bị chặn, không thể tạo issue, mở PR, viết bình luận
    • Với một startup có vốn đầu tư VC, các chỉ số hoạt động trên GitHub rất nhạy cảm, nhưng Archestra coi trọng chất lượng hơn là các chỉ số bị thổi phồng bởi AI slop

  • Giới hạn của thiết lập GitHub

    • GitHub không có cách đơn giản để quản lý whitelist trực tiếp cho người viết bình luận hay người tạo PR trong kho mã nguồn mở
    • Thiết lập “Limit to prior contributors” sẽ chặn việc bình luận trên issue và PR từ những người chưa từng commit trước đó vào main
    • Thiết lập này không phân biệt được bot AI với các lập trình viên thật mới đến để làm bounty, vì cả hai đều bị xem là người chưa từng đóng góp trước đó

  • Whitelist bằng cờ --author

    • GitHub xác định một tài khoản là prior contributor nếu tài khoản đó được liên kết với author của commit trên nhánh main
    • Mỗi Git commit có hai trường định danh là author và committer, và hai giá trị này có thể khác nhau
    • Dùng cờ --author của Git có thể tạo một commit được gán cho người khác; nếu email khớp với tài khoản GitHub đó thì GitHub sẽ liên kết commit với hồ sơ tương ứng và cấp trạng thái cộng tác viên
    • Mọi tài khoản GitHub đều có email noreply theo định dạng <id>+<username>@users.noreply.github.com
    • Sau khi tra cứu ID người dùng qua API, nhóm chỉ định author của commit theo định dạng email đó
    gh api users/their-username --jq '.id'  
git commit \  
--author="their-username <ID+their-username@users.noreply.github.com>" \  
-m "chore: add their-username to external contributors"
    • Khi push commit này lên main, người dùng bên ngoài sẽ hiện là author, còn tài khoản Archestra là committer; GitHub từ đó xem người dùng đó là prior contributor và cấp ngay quyền bình luận

  • Luồng onboarding thực tế

    • https://archestra.ai/contributor-onboard - Trên website, quy trình onboarding bao gồm quy tắc AI có trách nhiệm và CAPTCHA
    • GitHub Action - Khi người dùng gửi biểu mẫu, hệ thống tra cứu GitHub ID của họ, thêm handle vào file EXTERNAL_CONTRIBUTORS.md, rồi push một commit lên main với tài khoản người dùng đó là author
    • Người dùng - Được đưa vào whitelist và có quyền truy cập kho lưu trữ
    • Trong khi GitHub báo cáo tăng trưởng mạnh ở các chỉ số quy mô lớn bao gồm cả hoạt động do AI tạo ra, các nhóm dự án mã nguồn mở lại phải tự tay dọn AI slop trong kho và còn phải dựng giải pháp lách hạn chế để duy trì mức độ tham gia của người thật
    • AI slop không chỉ đẩy những người muốn đóng góp nghiêm túc vào giữa biển nhiễu, làm họ mất động lực, mà còn tạo ra rủi ro bảo mật khi kẻ tấn công cố dẫn dắt cuộc trò chuyện bằng bot AI như trong repo LiteLLM

Bài viết liên quan

1 bình luận

 
GN⁺ 9 giờ trước
Ý kiến trên Hacker News

  • Người đóng góp cho kho có quyền cao hơn, chẳng hạn có thể bỏ qua yêu cầu phê duyệt để chạy fork PR, nên cách này có tác động bảo mật bị bỏ sót
    Tài liệu GitHub cũng cảnh báo rằng với cấu hình “chỉ yêu cầu phê duyệt cho người đóng góp lần đầu”, người dùng đã từng có commit hoặc PR được hợp nhất vào kho sẽ không còn cần phê duyệt nữa, và kẻ xấu có thể đạt điều kiện này bằng cách được chấp nhận một thay đổi vô hại như sửa lỗi chính tả đơn thuần

    • Nói đúng. Người ngoài tổ chức thì không đáng tin, nên mặc định phải là yêu cầu phê duyệt với mọi người đóng góp bên ngoài
    • Đó không phải tác động bảo mật
      Nếu chỉ vì một PR hoàn toàn vô hại của ai đó đã được hợp nhất vào kho mà mọi thứ trở nên kém an toàn, thì bản thân kho đó vốn đã ở trong trạng thái không an toàn rồi

  • Vấn đề là GitHub lại để chuyện này có thể xảy ra. Chỉ cần đặt ra vài yêu cầu rất cơ bản cho việc viết bình luận và tạo PR thì đã không đến mức này
    Và cũng mong họ cho phép xóa PR giống như có thể xóa issue

    • Hiện tại họ đang làm tính năng cho phép quản trị viên lưu trữ PR
      Mục tiêu là để maintainer kiểm soát tốt hơn cách họ quản lý đóng góp cho kho. PR đã lưu trữ sẽ chỉ hiện với quản trị viên, còn bản ghi đóng góp vẫn sẽ tiếp tục truy cập được để phục vụ kiểm toán hoặc yêu cầu của tổ chức/compliance. Không biết tính năng như vậy có hữu ích không
    • Nhận định này đúng. Cũng như chuyện tránh nhận email spam không phải là việc mỗi cá nhân phải tự “tự lo liệu”, đây cũng không phải vấn đề mà cộng đồng mã nguồn mở hay từng dự án riêng lẻ phải tự xử lý
    • Tôi không hiểu lợi ích của việc xóa PR thay vì đóng nó lại là gì. Nếu để ở trạng thái đóng thì còn phát tín hiệu về những PR nào không được chấp nhận, còn xóa đi thì mất lợi ích đó

  • Spam PR là vấn đề lớn với các kho có treo bounty. Có lẽ GitHub nên tạm chặn tạo PR đối với những tài khoản có hơn 95% PR bị từ chối

    • Tôi muốn GitHub có một hệ thống kiểu cấp token 1 PR chẳng hạn
      Nếu ai đó tham gia thảo luận có ý nghĩa và tỏ ra có ý tưởng tốt để giải quyết issue hay tính năng nào đó, ban đầu có thể cấp cho họ một token PR; nếu chất lượng PR tốt thì cấp thêm vài cái, rồi cuối cùng nâng họ thành người đóng góp được tự do tạo PR. Sẽ tốt nếu issue cũng có hệ thống tương tự, dù tôi không rõ nó nên trông ra sao khi issue là điểm khởi đầu của việc đóng góp PR. Chỉ là GitHub/MS muốn bán đăng ký Copilot và token, còn PR do LLM tạo ra cũng là một phần trong mô hình kinh doanh đó, nên có lẽ chuyện này khó xảy ra trên thực tế
    • GitHub không có động lực để chặn AI. Chuyện này giống như bảo một công ty quảng cáo tích hợp trình chặn quảng cáo vào chính trình duyệt của họ vậy
    • Vấn đề là bot có thể cứ tạo tài khoản GitHub mới và tiếp tục spam mãi. Dù vậy, đây vẫn có thể là một lớp phòng thủ đơn giản chấp nhận được để bắt đầu
    • GitHub và Microsoft đang tích cực góp phần tạo ra vấn đề này, nên tại sao họ lại thừa nhận lỗi của chính mình?

  • Tôi tự hỏi liệu hệ thống chấm điểm dựa trên Elo có giúp giảm kiểu vấn đề này không
    Chẳng hạn đánh giá người đã hợp nhất PR thành công vào một dự án nhất định, người đã được công nhận là issue thực sự, người có chất lượng phản hồi được đo bằng phản ứng của người dùng khác, rồi nhân thêm theo mức độ quan trọng của dự án nơi các hoạt động đó diễn ra. Nó có thể trở thành tiêu chí để tách đóng góp hiệu quả, thực sự hữu ích khỏi đóng góp ít công sức, mang tính spam, thay vì chia theo người hay AI. Có thể sắp xếp hoặc lọc issue và PR theo điểm Elo. Ở đây Elo chỉ là phép ẩn dụ cho điểm số theo ngữ cảnh, chứ không có ý lấy nguyên hệ thống Elo áp 1:1
    Điểm âm sẽ đến từ việc người dùng khác báo cáo nội dung mang tính spam hoặc issue không được công nhận, còn với những trường hợp thiện chí rõ ràng nhưng chưa dẫn tới PR được hợp nhất, hoặc issue gửi nhầm kho, hoặc PR tốt nhưng cần triển khai trước ở phần khác, thì có vẻ cần một vùng trung gian cho điểm trung tính hoặc dương nhẹ

    • Elo dễ bị thao túng đến đáng kinh ngạc
      Ví dụ thực tế từng có một người chơi cờ khá giỏi trong tù, và anh ta đã tạo ra một nhóm người chơi đánh bại mình để có Elo cao, rồi dùng chính họ để kéo điểm của mình lên thêm. Chỉ cần lặp lại quá trình đó là được
      Bất kỳ cơ chế nào có thể bị thao túng thì AI sẽ tìm ra cách thao túng. Ngay cả với cách trong bài gốc, chỉ cần một AI giành được tư cách người đóng góp thì nó có thể kéo các AI khác lên thành người đóng góp, và rồi cùng một vấn đề lại bắt đầu. Thậm chí không cần mục đích gì cả. Troll thì sẽ đi troll, còn troll có bot AI thì có thể đổ vào đó năng lượng vô tận. Ước gì có câu trả lời cho vấn đề này, nhưng tôi không biết
    • Bổ sung cho ai thắc mắc về Elo: Elo không phải chữ viết tắt mà là họ của một người. Thông tin chi tiết ở đây: https://en.wikipedia.org/wiki/Elo_rating_system
    • Là Elo chứ không phải ELO. Elo không phải từ viết tắt
      https://en.wikipedia.org/wiki/Elo_rating_system
    • Tôi đang xây một thứ tương tự và hiện tại đang thu thập dữ liệu
      Frontier users: 527,865
      Light indexed: 527,865
      Ready to queue: 9,083
      Fast scores ready: 0
      Activity events 24h: 30,266
      Fast scores completed 24h: 19,123
      Deep jobs completed 24h: 3,043
      Fast-score ETA: n/a
      Deep-hydrate ETA: 69h
      Stale running jobs: 0
      GitHub backpressure jobs: 19,113
      High automation signals: 4,608
      Medium automation signals: 1,327
      Completed jobs: 74,714
      Trở ngại lớn nhất là giới hạn tốc độ của GitHub. Với tốc độ này thì sẽ cần thêm hai tháng nữa mới đạt được mức bao phủ 98%, nhưng sau đó việc duy trì có vẻ sẽ khá đơn giản
    • Nghe khá giống Vouch của Mitchell Hashimoto: https://github.com/mitchellh/vouch

  • Đây là kết quả của việc rao giảng với tất cả mọi người về việc AI viết code giỏi đến mức nào
    Những người bán AI đã khởi đầu chuyện đó, và lạ là rất nhiều indie developer, kể cả những người khá được kính trọng trong ngành, cũng nhảy lên theo. Việc Facebook giờ sa thải người rồi lại nói là vì AI quá xuất sắc chỉ càng đổ thêm dầu vào lửa. Giờ đã có những người tin chắc người bạn AI của họ tạo ra lượng code khổng lồ, và họ đem nộp đống code đó vào những dự án đã hoàn toàn quá tải

    • Có lẽ là chuyện cowboy coder có được các nữ cao bồi coder ảo rồi đem bán cho mọi người
      Dù có được kính trọng hay không, không phải cứ là nhà phát triển solo thì lúc nào cũng có đủ năng lực tối thiểu để không trở thành cowboy. Có thể là thiếu kinh nghiệm, cũng có thể là thiếu năng lực bẩm sinh. Dù vậy tôi không hoàn toàn tin vào câu chuyện này, vì ngay từ “giai đoạn đầu” đã có một sự thúc đẩy rất mạnh theo kiểu top-down

  • Việc đó lại xảy ra trên tên miền .ai mới thật mỉa mai

    • Tôi không thấy đặc biệt mỉa mai. Không phải đang nói AI là xấu, mà là đang nói nó có thể bị lạm dụng
    • Mong trang web sửa lại phần code cuộn trang một chút. Bực mình đến mức tôi không đọc nổi bài
    • Kiểu như một công ty xây trên rác AI lại nói “Tôi đâu biết AI sẽ làm dự án của tôi thành bãi rác!”
    • Không chỉ là tên miền. Đây là agentic stack. Nói cách khác, dùng chính sản phẩm của công ty này là có thể tạo ra đúng kiểu PR mà họ đang than phiền ở đây

  • Có phải lời giải cho mọi thứ cuối cùng vẫn là nhiều catgirl hơn không? [1] Proof of work ban đầu vốn là để đối phó với spam email, còn spam PR chỉ là ví dụ mới nhất trong truyền thống dài đó mà thôi
    1- https://anubis.techaro.lol

    • Proof of work không hiệu quả ở đây cũng như nó đã không hiệu quả với email
      Nỗ lực để tạo ra proof of work hợp lệ, trong bất kỳ cách triển khai nào, cuối cùng cũng luôn gây bất lợi cho người dùng bình thường. Người có động cơ spam thì lúc nào cũng có thể làm nhanh hơn và hiệu quả hơn
      Nếu laptop của bạn quá chậm nên không thể gửi PR thì sao? Chỉ cần thuê hash power của ai đó, và thế là bạn đã tạo ra một hệ thống nơi người ta trả tiền cho chủ botnet chỉ để gửi một bản sửa lỗi chính tả lên kho GitHub. Có lý do HashCash không được dùng trong thực tế. Nghe thì dễ thương, nhưng các động lực lệch lạc đến mức nó chỉ hoạt động nếu giả định một môi trường chân không nơi mọi người đều không gian lận
    • Anubis thực ra không phải mèo. Trong thần thoại Ai Cập, Anubis là thần chết và có đầu loài chó. Anime catgirl và dog girl thoạt nhìn có thể trông giống nhau
    • Tôi nghĩ Anubis là để chặn crawler chứ không phải tác tử tạo PR. Ở đây proof of work sẽ không hiệu quả, vì tác tử cứ việc tính toán xong là được

  • Văn phong trong tài liệu onboarding có mùi AI rất quen thuộc. Ngay trong phần trích dẫn cũng thấy dấu em dash và kiểu câu “không phải A mà là B”
    Tôi hiểu có thể là lấy độc trị độc, hoặc như đã nói, đơn giản là không có thời gian. Nhưng nhìn tổng thể thì vẫn giống một phản ứng nửa vời, chưa tới nơi tới chốn

    • Toàn bộ bài viết trông rõ ràng là do LLM tạo ra
      Tôi hiểu là con người có sắp xếp ý tưởng vào đó, nhưng việc bảo LLM “hãy biến cái này thành một bài blog” thì theo tôi là nội dung ít công sức không hợp với HN. Dù vậy, nó ít nhất cũng khơi ra được thảo luận rằng cách cơ bản là “giới hạn cho người đóng góp” có thể là một ý tưởng tồi về mặt bảo mật
    • Dùng AI cho dự án của chính mình là một chuyện, còn bị đóng góp AI do người khác hoặc bot gửi tới làm ngập lụt lại là chuyện khác

  • Khi đọc đoạn “nếu email khớp với tài khoản GitHub thì GitHub sẽ liên kết commit với hồ sơ và cấp trạng thái người đóng góp”, tôi đã lo rằng chẳng phải sẽ hỏng nếu địa chỉ email của người đóng góp thay đổi sao
    Vì trong nhiều năm tôi từng đóng góp cho nhiều dự án bằng các địa chỉ email nay không còn tồn tại nữa
    Nhưng có vẻ trên thực tế họ không dùng địa chỉ email ghi trong commit git gốc của tác giả, mà dùng địa chỉ do GitHub tạo với phần duy nhất chứa ID và username của người dùng GitHub. Nếu vậy thì ngay cả khi tác giả đổi email, nó vẫn có thể tiếp tục hoạt động. Dù vậy, nếu người đóng góp mất quyền truy cập tài khoản và phải tạo tài khoản mới thì có thể vẫn bị vỡ, nhưng chắc trường hợp đó ít gặp hơn

  • Câu trả lời cho “Có lẽ nên ngừng giao các bài test thú vị cho ứng viên chăng?” là đúng vậy

    • Có vẻ công ty này trả tiền nếu hoàn thành bài đó, nên có thể cũng không tệ đến thế
    • Các lập trình viên: hãy ngừng phỏng vấn whiteboard vì nó không đo được những thứ liên quan đến công việc thực tế
      Cũng vẫn là các lập trình viên: đừng bắt giải quyết vấn đề thực tế
    • Ngay từ đầu tôi đã không hiểu là nó thú vị với ai nữa