Gitea: Akun Giteabot telah disusupi

Sementara itu, harap berhati-hati saat mengunduh binari rilisan kami, terutama yang windows, hingga pemberitahuan lebih lanjut. Misalnya perhatikan ukuran binari, atau akhiran file .exe ganda.
Kami telah menemukan binari .exe kami dalam rilis 1.4.2 juga diubah.

Kami bekerja keras untuk mengikuti semua jalur, membersihkan dan kembali ke bisnis sehari-hari sesegera mungkin.

@daviian Mungkin perlu menandatangani rilis?

@Mauladen Terima kasih atas masukan Anda. Kami pasti akan membahas ini.

Aduh! Ya, binari yang ditandatangani akan ideal.

@Mauladen Kami telah membangun kembali binari untuk rilis 1.4.2 hanya untuk memastikan kami menyediakan yang aman.

Atau apakah Anda bermaksud sesuatu yang lain?

Ini normal. Kami melakukan retage 1.4.2 untuk memicu CI untuk membangun kembali binari karena biner windows untuk rilis itu telah dihapus dan ada yang baru ditambahkan yang berbahaya

@daviian , Mungkin @Mauladen berarti komit rilis 1.4.2 tanpa tanda tangan GPG, tetapi 1.4.1 adalah

Masih perlu mengedit daftar perubahan

@axifive komit di mana tidak gpg ditandatangani oleh pengguna tetapi github yang melakukannya secara otomatis (dengan kunci github) ketika merger sama dengan penulis PR. Saya tidak akan menganggapnya lebih aman karena jika akun github dikompromikan, saya juga akan ditampilkan sebagai "terverifikasi". Tapi kita bisa mulai menandatangani tag dari sekarang (akan didiskusikan). Sebagai informasi, kami sedang mengerjakan penandatanganan biner karena lebih mudah merusak biner thzan sebagai pohon komit git.

Anda harus mengunggah tarball yang dibuat oleh git-archive (selain yang dibuat oleh github secara otomatis) yang Anda tandatangani dengan signify . Anda bisa mendapatkan ide tentang cara kerja/tampilannya di sini:

• https://github.com/nicklan/pnmixer/blob/master/MAINTING.md#releasing
• https://github.com/nicklan/pnmixer/releases/tag/v0.7.2

Libressl menggunakan teknologi yang sama.

Apakah ada informasi lagi tentang ini? Apa muatan binernya? Apakah pengguna akan diberitahu tentang ini melalui posting blog atau apa? Apakah ada binari linux yang dikompromikan? Saya agak khawatir tentang apa yang mungkin telah dilakukan hal-hal ini pada server saya. Saya sangat khawatir bahwa saya hanya mengetahui tentang penjelajahan halaman masalah ini secara kebetulan vs pemberitahuan resmi di halaman proyek/blog

Apakah rilis Gitea 1.4.2 aman untuk diperbarui dari kode sumber pada saat ini?

Pada titik ini, tidak jelas bagi saya apakah hanya binari yang terpengaruh. Bagaimana Anda memverifikasi ini? Apakah cabang Anda terlindungi?

shasum berbeda pada binari yang saya unduh pada 6/4 dan 6/7 meskipun jumlah bytenya sama:

$ sha256sum gitea-1.4.2-linux-amd64*
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d  gitea-1.4.2-linux-amd64.1

$ ls --color=tty -l gitea-1.4.2-linux-amd64*
-rwxr-xr-x 1 matt matt 53674800 Jun  4 20:39 gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 matt matt 53674800 Jun  7 08:18 gitea-1.4.2-linux-amd64.1

Ingin menyelenggarakannya di suatu tempat sehingga orang-orang dapat memisahkannya?

Mengunggah binari di sini: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. Saya akan menempatkannya di tempat yang lebih permanen jika perlu.

Pertanyaan - apakah hanya binari di situs web yang terpengaruh, atau apakah repositori juga terpengaruh? Saya bertanya karena kemarin saya mendengar tentang Gitea dan mengkloning dan membangun cabang v1.4.

Benar-benar ingin info lebih lanjut jika sumbernya sendiri dikompromikan atau hanya binari. Saya menjalankan skrip untuk memeriksa pembaruan/pembangunan dari git nightly dan cukup beruntung untuk melewatkan ini karena waktunya.

Apakah rilis 1.4.2 saat ini diverifikasi bersih? Jika kami tahu itu tercemar, kami harus menariknya secepatnya dan meletakkannya di tempat lain untuk dianalisis, jika tidak, orang akan tetap mengunduhnya jika mereka tidak melihat masalah ini. Saya setuju dengan @CountMurphy , dapatkah kita menambahkan sesuatu ke README sehingga benar-benar terlihat?

Bisakah kami mendapatkan hash sehingga kami dapat memeriksa apakah binari kami terpengaruh? Gitea 1.4.1 saya (linux amd64) terlihat seperti ini:
$sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

Saya baru saja mengunduh gitea 1.4.1 linux-AMD-64 dan saya mendapatkan d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 sebagai sha256 juga

@mikedilger Lihat: https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229

Untuk membuatnya sangat jelas: tidak ada yang tahu apa-apa dan satu-satunya hash yang aman adalah yang saat ini ditemukan di sini: https://github.com/go-gitea/gitea/releases

Untuk Gitea 1.4.2 di amd64, itu berarti:

Maaf, saya salah memahami https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229 yang berarti bahwa kedua binari telah disusupi.

Saya telah mengedit posting ini untuk menghilangkan ambiguitas tentang apa yang sebenarnya kita ketahui.

7dededed on: menurut komentar ini (https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229), ada dua shas e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 dari 4 Juni4693906406483dbedad5705843d4906405743d

Apakah kita mengatakan bahwa keduanya dikompromikan atau hanya salah satunya? Sebagai catatan, yang ada di server saya adalah e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 mulai 5 Juni.

@christianbundy , Tolong jangan terburu-buru menyimpulkan, tunggu tanggapan dari anggota Tim

Tolong jangan terburu-buru mengambil kesimpulan, tunggu respon dari anggota Tim

Maaf tentang itu, saya pikir hash file akan segera diposting oleh anggota tim dan tidak menyadari bahwa info tersebut berasal dari orang lain yang _juga_ dalam kegelapan. Apakah ini saluran yang benar untuk menonton perkembangan terbaru? Saya telah mematikan server saya dan memerlukan lebih banyak informasi untuk mengetahui apakah saya telah terinfeksi.

Saya melihat suntingan Anda mencoret entri yang saya tunjuk. NAMUN, bukankah ini terlalu dini untuk menarik kesimpulan? Bagaimana kita tahu pasti e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 baik-baik saja?

Kami masih kehilangan beberapa informasi (kemungkinan tidak lengkap):

• [ ] Binari mana yang dikompromikan dan apa checksumnya?
• [ ] Kapan akun bot disusupi?
• [ ] Apakah repositori sumber dikompromikan (ini mungkin mudah untuk memeriksa apakah Anda memiliki versi repo yang dikloning dari beberapa waktu lalu, maka Anda mungkin dapat memeriksa perbedaan atau bukti dorongan paksa).

Saya mendapatkan:

# ls -la gitea-1.4.1-linux-amd64
-rwxr-xr-x 1 gitea gitea 53663640 May  3 08:02 gitea-1.4.1-linux-amd64

Dengan sha256sum d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851

dan saya baru saja mengunduh gitea-1.4.2-linux-amd64 :

# ls -la gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 root root 53674800 Jun  7 14:18 gitea-1.4.2-linux-amd64

Dengan sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d yang cocok dengan file .sha256 yang disediakan: gitea-1.4.2-linux-amd64: OK yang seharusnya aman. (Baik?)

[...] Kami telah membangun kembali binari untuk rilis 1.4.2 hanya untuk memastikan kami menyediakan yang aman. [...]

Saya mengunggah gitea-1.4.2-linux-amd64 untuk analisis di sini , tetapi tidak terlalu jelas.

Akan menonton masalah ini dan membuat instalasi gitea saya offline untuk saat ini.

Bagaimana kita tahu pasti e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 baik-baik saja?

@shuhaowu saya mengatakan bahwa c843d462 baik-baik saja, bukan e14e54f3 . Kami mengetahui hal ini karena itulah file yang saat ini disajikan di GitHub, yang baru saja mereka buat ulang.

Jika 1.4.2 dibangun kembali, itu harus ditandatangani dan diverifikasi seperti rilis valid lainnya. Tidak melakukannya hanya menambah kebingungan.

@xcolor

Mengunggah binari di sini: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

Satu-satunya perbedaan antara kedua biner ini adalah bahwa sekitar 2000 instance movabsq $63663754793, %rcx diganti dengan movabsq $63663969431, %rcx . Saya tidak bisa mengatakan dengan tepat apa yang berubah secara perilaku, tetapi saya pikir sangat tidak mungkin bahwa itu cukup untuk menjadi jahat.

Mungkin mengeluarkan rilis 1.4.3 baru (ditandatangani?) dengan kode yang dikenal aman, atau apakah itu akan lebih membingungkan?

@justinclift Saya suka ide itu, juga posting blog dan sesuatu di README tentang situasinya akan membantu menjernihkan semuanya.

@spaghetti2514

Di satu sisi, Anda benar -- perbedaan antara _those_ dua biner mudah dilihat.

Di sisi lain, tim Gitea belum benar-benar memposting binari mana yang terpengaruh, memposting hash SHA256 apa pun, atau benar-benar mengatakan _apa pun_ yang akan membantu kami memahami kompromi Seperti yang ditunjukkan orang lain, kami hampir tidak memiliki cukup info untuk menentukan apa yang terjadi dan siapa yang terpengaruh.

Saya frustrasi untuk menunjukkan bahwa kita mungkin harus mengasumsikan yang terburuk dan menunggu langkah-langkah diagnostik dari tim inti. Dengan itu, saya menghargai Anda memposting diff yang dibongkar.

Apakah ini yang kamu cari? https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

Terima kasih atas pembaruannya @lafriks !

Saya telah memperbarui deskripsi masalah dengan info tambahan. Itu tidak begitu buruk karena bisa saja. Kami ingin setransparan mungkin, jadi buat masalah ini segera setelah kami membersihkan & memperbaiki semuanya dan karena ini adalah pertama kalinya hal seperti ini terjadi, jadi mungkin kami seharusnya memberikan lebih banyak informasi lebih cepat, maaf telah menyebabkan kebingungan.

@lafriks Terima kasih atas pembaruannya! Bisakah Anda memposting kunci PGP Anda yang dapat kami gunakan ke depan untuk memverifikasi komit?

@4oo4 tag ditandatangani oleh salah satu kunci GPG merger sendiri, karena semua PR digabung menggunakan Squash&Merge, mereka tidak ditandatangani (atau mungkin ditandatangani oleh sihir GitHub :))

Rilis akan ditandatangani oleh kunci GPG yang akan dibuat sebelum rilis 1.5.0, kami akan mempublikasikannya di README.md, gitea docs dan di posting blog.

Sebagai pengguna 386, saya dapat mengonfirmasi bahwa biner gitea-1.4.1-linux-386 saat ini tersedia di halaman Rilis cocok dengan versi yang saya unduh pada 4 Juni ( cf6344b4 ).

karena semua PR digabungkan menggunakan Squash&Merge, mereka tidak ditandatangani (atau mungkin ditandatangani oleh sihir GitHub :))

Jangan gunakan tombol gabung, itu pada dasarnya tidak aman dan kunci gpg acak. Gabungkan secara lokal dan dorong penggabungan.

@mappu gitea v1.4.1 belum terpengaruh dan sekarang v1.4.2 telah dirilis ulang.

Anda harus mengunggah tarball yang dibuat oleh git-archive (selain yang dibuat oleh github secara otomatis) yang Anda tandatangani dengan signify .

Sebenarnya, Anda bahkan tidak perlu membuat arsip dan mengunggahnya lagi. Anda dapat menandatangani yang dibuat oleh GitHub, karena itu dapat dilakukan secara berulang.

Berikut ini skrip kecil untuk itu: https://github.com/rugk/gittools/blob/master/signrelease.sh

@rugk Skrip yang terlihat berguna. :senyum:

Apakah ada anggota tim yang berkontribusi mendapatkan arsip 1.4.2 sebelum penemuan pelanggaran?

Anda tampaknya telah meninggalkan banyak orang dalam kegelapan tentang apakah biner ini telah diubah untuk rilis Linux apa pun, yang merupakan bagian informasi yang cukup penting mengingat:

1) Sebagian besar penyebaran akan ke tumpukan Linux

2) Tumpukan Linux tidak terbiasa dengan trojan biner dan biasanya tidak cocok dengan alat terbaik untuk mendeteksi kode mencurigakan yang sudah berjalan di sistem secara terprogram.

Sementara saya ingin percaya bahwa ini adalah serangan bertarget Windows sederhana dan tidak lebih, fakta bahwa mereka menargetkan repositori khusus ini hanya beberapa hari menjadi lonjakan dramatis dalam pertumbuhan basis pengguna tampaknya menunjukkan upaya yang diatur dengan lebih baik. Saya sangat ragu bahwa siapa pun yang tahu apa yang mereka targetkan dan bagaimana melakukan hal semacam ini akan melewatkan kesempatan matang untuk menginfeksi host sebanyak mungkin.

@stanier dl.gitea.io tidak terpengaruh dan kami telah memverifikasi bahwa tidak ada binari lain yang dirusak

Jadi itu menjelaskan mengapa webproxy kami menolak untuk mengunduh gambar gitea terbaru dari hub.docker.com ...

@lafriks Jadi bisakah Anda memastikan bahwa c843d462 dan e14e54f3 keduanya aman? Jika CI menyediakan build dengan tanda tangan yang berbeda, maka pasti ada sesuatu yang berubah dalam kode sumber atau parameter yang digunakan kompiler untuk build. Ini adalah masalah teknis kecil dengan sendirinya, tetapi tidak pernah secara langsung dinyatakan di sini apakah musuh telah mengubah binari Linux 1.4.2 atau tidak, hanya binari .exe masing-masing yang disebutkan dalam komentar oleh @daviian.

Hanya untuk memperjelas, saya bertanya tentang binari halaman rilis repo GH, bukan dl.gitea.io, saya mengerti tidak ada yang dirusak di luar repo GH.

Tumpukan Linux tidak terbiasa dengan trojan biner dan biasanya tidak cocok dengan alat terbaik untuk mendeteksi kode mencurigakan yang sudah berjalan di sistem secara terprogram.

Hmmm, bukankah sebagian besar manajer paket (dan sejenisnya) memiliki ketentuan untuk memverifikasi setidaknya sha* checksum? Tidak harus hanya untuk mendeteksi malware, tetapi sebagai "ayo verifikasi bahwa unduhan tidak rusak".

@justinclift ya, tapi itu hanya berlaku untuk binari yang diinstal melalui manajer paket. Masalah yang dimaksud di sini berkaitan dengan unduhan langsung dari GitHub, yang sejauh pengetahuan saya tidak memiliki deteksi malware yang disematkan.

Ahhh. Istilah "Linux stacks" membuat saya bingung, karena saya lebih terbiasa mengunduh langsung sebagai hal yang sederhana (misalnya ketika membuat prototipe), daripada sesuatu yang akan dilakukan oleh solusi otomatis. Jangan khawatir. :senyum:

@stanier build itu
Saya mendapatkan semua biner selama penyelidikan dan dapat memberikan hash segera setelah saya sampai ke komputer pribadi saya.

Untuk semua, tolong hentikan argumen tentang rumor dan berikan masukan yang membangun.
Saya mengerti bahwa Anda mengkhawatirkan keamanan Anda dan kami sangat peduli akan hal itu (karena kami juga berada di tempat Anda sebagai pengguna gitea). Saat ini akses telah diubah dan kami tidak melihat aktivitas mencurigakan lagi. Kami telah melakukan masalah ini untuk menginformasikan sesegera mungkin agar transparan dan dapat menerima masukan dari setiap data yang berguna untuk menyelidiki atau melewatkan tempat karena tidak ada yang sempurna.
Kami akan melakukan post-mortem untuk menjelaskan apa yang terjadi dan kami secara definitif memikirkan tindakan untuk mencegah hal ini di masa depan.
Jika masalah ini menjadi liar, saya pikir kita perlu menutup untuk menyimpan hanya informasi yang berguna dan ringkas dan mengirim perdebatan ke perselisihan di mana ia harus pergi.

Untuk menghindari situasi seperti itu di masa depan kami akan mulai menandatangani semua binari dengan versi berikutnya. Saya telah membuat plugin untuk Drone yang dapat Anda temukan di https://github.com/drone-plugins/drone-gpgsign (dokumentasi untuk plugin ini harus dilakukan) yang akan menandatangani semua binari, kunci publik akan diunggah ke server unduhan dan ke server kunci, maka Anda akan selalu dapat memverifikasi binari dengan cara yang dapat dipercaya.

Hanya untuk menunjukkan kepada Anda contoh bagaimana tampilannya dan apa hasilnya, Anda dapat melihat di https://github.dronehippie.de/webhippie/ldap-proxy/49/18 dan https://dl.webhippie.de /misc/ldap-proxy/master/ , file serupa akan diunggah ke halaman unduhan Gitea dan ke rilis GitHub.

Jika menurut Anda plugin ini melewatkan sesuatu yang sangat penting, jangan ragu untuk membuka masalah pada repositori plugin dan saya dapat mengatasinya.

@sapk Terima kasih atas klarifikasinya. Saya minta maaf, itu benar-benar terlintas dalam pikiran saya bahwa proyek itu berbasis Golang-- sebagian besar masalah seperti ini berhubungan dengan perangkat lunak yang lebih lama jadi saya pikir pikiran saya melompat ke hubungan yang salah. Kesalahanku.

Saya sudah mulai melihat biner install.exe yang diunggah: https://grh.am/2018/a-look-at-the-compromised-gitea-release/

Tampaknya bukan hanya Gitea yang terkena ini, tetapi juga https://github.com/opencompany/www.opencompany.org/releases

Terima kasih atas penjelasan yang jelas.

Saya pikir masalah ini adalah alasan utama untuk melalui kemasan khusus distro. Ini membawa lebih banyak perhatian pada pengemasan dan potensi kode/biner berbahaya (terutama dalam kasus upaya kotor seperti itu). Akan sangat bagus untuk memiliki setidaknya paket Debian/RedHat/Archlinux untuk Gitea : yang akan mencegah banyak orang menjalankan biner sewenang-wenang di server produksi mereka :)

Apakah PGP-menandatangani rilis cukup? Mungkin. Pastikan untuk mengiklankan kunci publik Anda di banyak platform berbeda sehingga kompromi misalnya situs web Anda tidak membuat semua orang mengunduh kunci yang salah. (Tetapi paket Debian di backport akan menjadi <3)

(Juga, build yang dapat direproduksi ?)

Karena Anda akan mulai menandatangani rilis biner, dapatkah Anda juga mempertimbangkan untuk menandatangani gambar Docker yang didorong ke registri?

Tampaknya bukan hanya Gitea yang terkena ini, tetapi juga https://github.com/opencompany/www.opencompany.org/releases

Baru saja mengirim email kepada kontak mereka secara langsung, jika mereka belum melihat masalah GitHub mereka.

@graystevens Haruskah staf pastebin dihubungi untuk mematikan alamat pastebin itu, atau lebih baik menganalisis malware sepenuhnya terlebih dahulu sehingga dipahami dengan benar?

Terima kasih semuanya .. Akan mengunduh ulang dan memasang kembali server saya

@justinclift Saya akan melaporkan tempel ke PasteBin sekarang - Saya punya salinan kontennya sehingga kami dapat membuat ulang output untuk malware jika perlu. Teriakan yang bagus

Agar adil, go sekarang memiliki build yang dapat direproduksi: https://blog.filippo.io/reproduction-go-binary-byte-by-byte/
Itu mungkin cgo untuk sqlite dan beberapa build env yang membuatnya tidak dapat direproduksi.

Sekadar informasi, daftar hash yang dibangun kembali dan tidak tersentuh sebelumnya . Jika Anda memiliki hash itu, itu berarti Anda memiliki biner sebelum pembangunan kembali yang telah kami lakukan untuk mengatur ulang rilis 1.4.2 dan juga sebelum serangan. Jika demikian, Anda dapat tinggal bersama mereka.

156655506d373241fea6b8955acbe6fdc148f06b49b4f6e46d11cadcd00d7316  gitea-1.4.2-darwin-10.6-386
5730c1a471dfc2c055442360d431c950b3a4f266403c5f327c94a68b88e67a10  gitea-1.4.2-darwin-10.6-amd64
8c3cc2127161695dea512176cd4282711e8c57972f333253cc89597dfab002ef  gitea-1.4.2-linux-386
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
bca75d81c52b9aa57fd05b8f7ce0572abae3e1a008d8ab77840ca08c53975867  gitea-1.4.2-linux-arm-5
3aa791afce2e3450461038e09622fe04f34b891c47db641be50b6cc3f772645e  gitea-1.4.2-linux-arm64
fc73d06621fc23a944a2a8ee3b19fbd8edb972b0cdaefa67248eb885aa4d6240  gitea-1.4.2-linux-arm-6
5b76cd9b84846c09ba3627219a6cad99542a53d8eec71a427a433ab82eaabacf  gitea-1.4.2-linux-arm-7
4fafeabfa069066fd624364b47b5729f8f068545d4cd8a3620774a982937ac16  gitea-1.4.2-linux-mips64le
7d9e0afcd315f0efbfb26cab303b3fee3939fa0e081b0d3f4f480f950d0a9870  gitea-1.4.2-linux-mips64
7f2e3c1163823889bec1fdd34b4135149c83d53b6dc86f186821e51e0f839e53  gitea-1.4.2-linux-mipsle
a1b8338113d4fdb0360582ba18f6fce97722c779493e7d7e07594d78c7c3f003  gitea-1.4.2-linux-mips
82ad50932bd927ead2e7da4e4c575d94f88e0105a82eda4cce1df7c9fc5ba0dc  gitea-1.4.2-windows-4.0-386.exe
86d7332894390ccaedd39be891044d829f54d4cd71fa21fce5dbd9bc3abbce44  gitea-1.4.2-windows-4.0-amd64.exe

Pass pembersihan install.exe tampaknya melewatkan beberapa repositori:

• go-gitea/gitea-darkmode
• go-gitea/lgtm-cli
• go-gitea/yaml
• go-gitea/baut
• go-gitea/lgmt-go
• go-gitea/lgmt-docs

Sebagian besar sudah tua dan tidak terlalu relevan, tetapi mungkin bukan ide yang baik untuk menyimpan malware.

@lunny

• https://github.com/lunny/html2md/releases
• https://github.com/lunny/tango/releases
• https://github.com/lunny/nodb/releases

• https://github.com/go-xorm/dbweb/releases
• https://github.com/go-xorm/xorm/releases
• https://github.com/go-xorm/builder/releases
• https://github.com/go-xorm/ql/releases
• https://github.com/go-xorm/go-xorm.github.io/releases
• https://github.com/go-xorm/blog/releases
• https://github.com/go-xorm/website/releases
• https://github.com/go-xorm/cachestore/releases
• https://github.com/go-xorm/tidb/releases
• https://github.com/go-xorm/xorm-redis-cache/releases
• https://github.com/go-xorm/manual-zh-CN/releases
• https://github.com/go-xorm/manual-en-US/releases
• https://github.com/go-xorm/cmd/releases
• https://github.com/go-xorm/core/releases
• https://github.com/go-xorm/tests/releases
  

• https://github.com/go-tango/gos/releases
• https://github.com/go-tango/social-auth/releases
• https://github.com/go-tango/wego/releases
• https://github.com/go-tango/manual-en-US/releases
• https://github.com/go-tango/manual-zh-CN/releases
  

• https://github.com/go-xweb/xrun/releases
• https://github.com/go-xweb/log/releases
• https://github.com/go-xweb/docs-zh-CN/releases
• https://github.com/go-xweb/httpsession/releases
• https://github.com/go-xweb/xweb/releases
• https://github.com/go-xweb/uuid/releases
  

• https://github.com/goftp/leveldb-auth/releases
• https://github.com/goftp/xorm-auth/releases
• https://github.com/goftp/xorm-perm/releases
• https://github.com/goftp/posixfs-driver/releases
• https://github.com/goftp/ftp/releases
• https://github.com/goftp/qiniu-driver/releases
• https://github.com/goftp/multiple-driver/releases
• https://github.com/goftp/ftpd/releases
• https://github.com/goftp/file-driver/releases
  

• https://github.com/gobook/gobook/releases
• https://github.com/gobook/bookserver/releases
• https://github.com/gobook/blackfriday/releases
  

• https://github.com/tango-contrib/bind/releases
• https://github.com/tango-contrib/jwt/releases
• https://github.com/tango-contrib/cache-ledis/releases
• https://github.com/tango-contrib/cache-memcache/releases
• https://github.com/tango-contrib/cache-mysql/releases
• https://github.com/tango-contrib/cache-nodb/releases
• https://github.com/tango-contrib/cache-postgres/releases
• https://github.com/tango-contrib/cache-redis/releases
• https://github.com/tango-contrib/counting/releases
• https://github.com/tango-contrib/session-redis/releases
• https://github.com/tango-contrib/session-ssdb/releases
• https://github.com/tango-contrib/session-ledis/releases
• https://github.com/tango-contrib/authz/releases
• https://github.com/tango-contrib/basicauth/releases
• https://github.com/tango-contrib/binding/releases
• https://github.com/tango-contrib/cache/releases
• https://github.com/tango-contrib/captcha/releases
• https://github.com/tango-contrib/debug/releases
• https://github.com/tango-contrib/session/releases
• https://github.com/tango-contrib/xsrf/releases
• https://github.com/tango-contrib/dispatch/releases
• https://github.com/tango-contrib/tpongo2/releases
• https://github.com/tango-contrib/events/releases
• https://github.com/tango-contrib/rbac/releases
• https://github.com/tango-contrib/flash/releases
• https://github.com/tango-contrib/notify-discord/releases
• https://github.com/tango-contrib/renders/releases
• https://github.com/tango-contrib/session-nodb/releases
• https://github.com/tango-contrib/websocket/releases
  

• https://github.com/gobuild/goyaml/releases
• https://github.com/gobuild/got/releases
• https://github.com/gobuild/log/releases
• https://github.com/gobuild/oauth2/releases
• https://github.com/gobuild/gobuild/releases
• https://github.com/gobuild/gopack/releases
• https://github.com/gobuild/travis-autobuild/releases
• https://github.com/gobuild/awesome-go-tools/releases
  

Terima kasih. Apa pendekatan yang Anda gunakan untuk menemukan ini? Tampaknya pendekatan apa pun yang digunakan staf GitHub belum benar-benar 100% efektif. :mengernyit:

@jvanraaij @yaggytter terima kasih.

Karena setelah penyelidikan kami tidak ada hal lain yang terpengaruh dan tidak ada informasi lebih lanjut yang diberikan oleh GitHub, saya pikir masalah ini dapat diselesaikan. Adakah yang menulis posting blog tentang ini?

@lafriks Saya memposting posting blog ini kembali dalam beberapa hari setelah ini semua dimulai - ini lebih merupakan tampilan malware daripada masalah yang dihadapi, tetapi saya senang memperbaruinya jika Anda merasa ada sesuatu yang layak didokumentasikan 👍

Saya pikir dia ingin menulis posting blog post-mortem di blog gitea :)

@graystevens BTW tautan pemberitahuan situs Anda adalah 404. :senyum:

Karena setelah penyelidikan kami, tidak ada lagi yang terpengaruh dan tidak ada informasi lebih lanjut yang diberikan oleh GitHub ...

Sebagai titik data, meskipun GitHub belum mengatakan apa pun tentang ini di depan umum, secara pribadi mereka telah menanggapi (melalui email) untuk mengatakan secara efektif "Terima kasih, kami sedang menyelidiki."

Komentar di atas oleh @jvanraaij dan @yasuokav tampaknya juga membantu, karena (anehnya, dari PoV saya) GitHub tampaknya tidak menemukan contoh khusus malware tersebut sebelumnya.

Misalnya, semua repo yang terdaftar oleh @yasuokav di sini masih memiliki malware: https://github.com/crossoverJie/SSM/issues/36

Saya akan mengirim email lagi ke staf GitHub untuk menunjukkannya. Mereka tampaknya mendapatkan hal-hal yang diurus dalam beberapa hari ketika dihubungi langsung dengan daftar yang tepat untuk dilihat.

Ini menyedihkan untuk semua proyek lain, tetapi setidaknya untuk Gitea kami telah menyelesaikan masalah dengan benar, semoga ... :)

Menutup masalah ini karena binari sekarang ditandatangani, dan 2FA diimplementasikan.