Malware bertema Shai-Hulud ditemukan di library pelatihan AI PyTorch Lightning | Semgrep

 (semgrep.dev)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Versi PyPI lightning 2.6.2 dan 2.6.3 dipublikasikan pada 30 April 2026 lalu disalahgunakan dalam serangan rantai pasok, dan hanya dengan pip install lightning, direktori _runtime tersembunyi serta payload JavaScript yang diobfuscate dapat dijalankan
  • Payload berbahaya dijalankan otomatis saat modul diimpor, mencuri kredensial, token autentikasi, variabel lingkungan, dan rahasia cloud, serta juga mencoba mencemari repositori GitHub
  • Titik masuk serangan ini adalah PyPI, tetapi penyebaran worm dilakukan melalui npm; jika menemukan kredensial publikasi npm, ia menyuntikkan dropper setup.mjs dan router_runtime.js ke paket yang bisa dipublikasikan lalu menerbitkan ulang versi patch
  • Eksfiltrasi data menggunakan 4 kanal paralel: HTTPS POST, dead-drop pencarian commit GitHub, repositori GitHub publik yang dikendalikan penyerang, dan push langsung ke repositori korban; indikator yang tertinggal mencakup prefiks commit EveryBoiWeBuildIsAWormyBoi dan deskripsi repositori "A Mini Shai-Hulud has Appeared"
  • Malware menanam hook SessionStart pada .claude/settings.json milik Claude Code dan task runOn: folderOpen pada .vscode/tasks.json milik VS Code untuk menjalankan dropper setiap kali repositori dibuka, dan mesin yang mengimpor paket berbahaya selama periode terdampak harus dianggap telah sepenuhnya dikompromikan

Paket yang terdampak dan prosedur pemeriksaan

  • lightning adalah framework deep learning yang sering muncul dalam pohon dependensi tim yang membangun pengklasifikasi gambar, melakukan fine-tuning LLM, menjalankan model difusi, dan mengembangkan peramal deret waktu

  • Paket yang terdampak

    • lightning versi 2.6.2
    • lightning versi 2.6.3

  • Prosedur pemeriksaan pelanggan Semgrep

    • Jika belum menjalankan pemindaian proyek terbaru, Anda harus menjalankan pemindaian baru
    • Di halaman advisories, Anda dapat memeriksa apakah proyek baru-baru ini memasang versi paket tersebut
    • Kecocokan dapat diperiksa di dependency filter; jika muncul “No matching dependencies”, itu berarti proyek tidak sedang aktif menggunakan dependensi berbahaya tersebut
    • Jika ada kecocokan, repositori harus diaudit untuk mencari file tak terduga di direktori .claude/ dan .vscode/ yang tercantum pada indikator kompromi di bawah
    • Token GitHub, kredensial cloud, dan API key yang mungkin pernah berada di lingkungan terdampak harus diganti
    • Saran umum terkait respons serangan rantai pasok dan masa tunggu dibahas di $foo compromised in $packagemanager dan Attackers are Still Coming for Security Companies

Struktur penyebaran dari PyPI ke npm

  • Berbeda dari mini Shai-Hulud yang langsung menargetkan npm, titik masuk serangan kali ini adalah PyPI
  • Payload berbahaya tetap berupa JavaScript, dan penyebaran worm terjadi melalui npm
  • Jika malware yang dijalankan menemukan kredensial publikasi npm, ia menyuntikkan dropper setup.mjs dan router_runtime.js ke semua paket yang bisa dipublikasikan dengan token tersebut
  • Setelah itu, scripts.preinstall diatur untuk menjalankan dropper, versi patch dinaikkan, lalu paket dipublikasikan ulang
  • Pengembang turunan yang memasang paket tersebut akan menjalankan keseluruhan malware di mesin mereka sendiri, diikuti pencurian token dan infeksi worm paket

Cara eksfiltrasi data

  • Fungsi pencurian berbagi mekanisme dan desain dengan kampanye Mini Shai-Hulud sebelumnya, dan menggunakan 4 kanal paralel agar data tetap bocor meski jalur tertentu diblokir
  • Serangan ini mengandung tema Shai-Hulud, termasuk pembuatan repositori publik bernama EveryBoiWeBuildIsaWormBoi
  • Struktur indikator serangan cocok dengan kampanye mini Shai-Hulud sebelumnya, dan pesan commit berbahaya menggunakan prefiks EveryBoiWeBuildIsAWormyBoi untuk membedakannya dari serangan Mini Shai-Hulud asli

  • Transfer C2 melalui HTTPS POST

    • Data hasil pencurian segera di-POST ke server yang dikendalikan penyerang melalui port 443
    • Domain dan path disimpan sebagai string terenkripsi di dalam payload untuk mempersulit analisis statis

  • Dead-drop pencarian commit GitHub

    • Malware mem-polling API pencarian commit GitHub untuk mencari pesan commit dengan prefiks EveryBoiWeBuildIsAWormyBoi
    • Pesan commit membawa token dengan encoding Base64 ganda dalam format EveryBoiWeBuildIsAWormyBoi:<base64(base64(token))>
    • Token yang telah didekode kemudian digunakan untuk autentikasi klien Octokit untuk operasi berikutnya

  • Repositori GitHub publik yang dikendalikan penyerang

    • Repositori publik baru dibuat dengan nama kata acak dari Dune dan deskripsi "A Mini Shai-Hulud has Appeared"
    • Deskripsi ini bisa langsung dicari di GitHub
    • Kredensial hasil pencurian di-commit sebagai results/results-<timestamp>-<n>.json, di-encode Base64 lewat API tetapi isi internalnya adalah JSON biasa
    • File yang melebihi 30MB dipecah menjadi chunk bernomor
    • Pesan commit kamuflase menggunakan chore: update dependencies

  • Push langsung ke repositori korban

    • Jika malware memperoleh token server GitHub ghs_, ia akan langsung mendorong data hasil pencurian ke semua branch dari GITHUB_REPOSITORY milik korban

Target pencurian

  • Malware menargetkan kredensial di file lokal, environment, pipeline CI/CD, dan penyedia cloud

  • Sistem file

    • Memindai lebih dari 80 path file kredensial untuk mencari token ghp_, gho_, dan npm_
    • Memproses hingga 5MB per file

  • Shell dan variabel lingkungan

    • Menjalankan gh auth token
    • Membuang semua variabel lingkungan dari process.env

  • GitHub Actions

    • Pada runner Linux, malware membuang memori proses Runner.Worker menggunakan Python bawaan
    • Mengekstrak semua rahasia yang ditandai "isSecret":true serta GITHUB_REPOSITORY dan GITHUB_WORKFLOW

  • Organisasi GitHub

    • Memeriksa scope token repo, workflow
    • Menelusuri rahasia organisasi GitHub Actions

  • AWS

    • Mencoba memanggil sts:GetCallerIdentity menggunakan variabel lingkungan, profil ~/.aws/credentials, IMDSv2 169.254.169.254, dan ECS 169.254.170.2
    • Mengenumerasi dan mengambil semua nilai dari Secrets Manager serta parameter SSM

  • Azure

    • Menggunakan DefaultAzureCredential untuk mengenumerasi subscription dan mengakses rahasia Key Vault

  • GCP

    • Melakukan autentikasi dengan GoogleAuth
    • Mengenumerasi dan mengambil semua rahasia dari Secret Manager
    • Cakupan target mencakup lingkungan pengembangan lokal, runner CI, dan tiga penyedia cloud utama
    • Semua mesin yang mengimpor paket berbahaya selama periode terdampak harus dianggap sepenuhnya dikompromikan

Menjaga persistensi melalui alat pengembang

  • Setelah masuk ke dalam repositori, malware menargetkan alat pengembang yang umum dipakai, yaitu Claude Code dan VS Code, untuk menanam hook persistensi

  • Claude Code

    • Malware menulis hook SessionStart dengan matcher: "*" ke file konfigurasi Claude Code milik repositori, .claude/settings.json
    • Hook tersebut mengarah ke node .vscode/setup.mjs
    • Hook akan berjalan setiap kali pengembang membuka Claude Code di repositori yang terinfeksi, tanpa memerlukan penggunaan alat lain atau tindakan pengguna selain memulai sesi

  • VS Code

    • Untuk menargetkan pengguna VS Code, malware menanam task runOn: folderOpen di .vscode/tasks.json
    • node .claude/setup.mjs dijalankan setiap kali folder proyek dibuka

  • Dropper setup.mjs

    • Kedua hook memanggil setup.mjs, bootstrapper runtime Bun mandiri yang self-contained
    • Jika Bun belum terpasang, ia diam-diam mengunduh bun-v1.3.13 dari GitHub releases
    • Menangani Linux x64, Linux arm64, Linux musl, macOS x64, macOS arm64, Windows x64, dan Windows arm64
    • Setelah itu, ia menjalankan payload penuh .claude/router_runtime.js sebesar 14.8MB dan membersihkan file dari /tmp

  • Workflow GitHub Actions berbahaya

    • Jika malware memiliki token GitHub dengan izin tulis, ia mendorong workflow bernama Formatter ke repositori korban
    • Pada setiap push, workflow ini membuang semua rahasia repositori melalui ${{ toJSON(secrets) }}
    • Hasilnya diunggah sebagai artifact Actions yang dapat diunduh bernama format-results
    • Actions dipin ke commit SHA tertentu agar tampak normal
    • Repositori yang menerima paket lightning terinfeksi di CI dan memiliki token berizin tulis harus mengaudit file-file tersebut

Indikator kompromi

  • Indikator yang dapat dicari

    • Pesan commit dengan prefiks EveryBoiWeBuildIsAWormyBoi digunakan sebagai pembawa token dead-drop dan dapat ditemukan lewat pencarian commit GitHub
    • Repositori GitHub dengan deskripsi "A Mini Shai-Hulud has Appeared" adalah repositori eksfiltrasi penyerang dan dapat dicari langsung

  • Paket

    • lightning@2.6.2
    • lightning@2.6.3

  • File dan artefak sistem

    • _runtime/start.py: loader Python yang menginisialisasi payload saat impor
    • _runtime/router_runtime.js: payload JavaScript yang diobfuscate dan runtime Bun berukuran 14.8MB
    • _runtime/: direktori yang ditambahkan ke versi paket berbahaya
    • .claude/router_runtime.js: salinan malware yang disuntikkan ke repositori korban
    • .claude/settings.json: konfigurasi hook Claude Code yang disuntikkan ke repositori korban
    • .claude/setup.mjs: dropper yang disuntikkan ke repositori korban
    • .vscode/tasks.json: task auto-run VS Code yang disuntikkan ke repositori korban
    • .vscode/setup.mjs: dropper yang disuntikkan ke repositori korban

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Mungkin ini cuma ilusi frekuensi, tapi belakangan ini memang terlihat cukup banyak serangan rantai pasok terkenal pada paket-paket besar
    Bahkan di beberapa halaman teratas HN saat ini ada beberapa tulisan yang membahas kasus berbeda
    Kalau melihat kembali left-pad 10 tahun lalu, rasanya serangan yang berhasil sekarang memang lebih banyak daripada dulu, dan mungkin memang begitu
    Nilai dari serangan yang berhasil juga pasti makin besar, tapi saya penasaran apakah kemampuan untuk mendeteksinya sebelum rilis paket benar-benar membaik secara komunitas secara keseluruhan
    Perusahaan perangkat lunak komersial seharusnya bisa berbuat lebih baik, tetapi tampaknya masih kurang alat yang universal dan mudah dipakai untuk kasus ketika sesuatu bermula dari kode hobi/amatir lalu menjadi dependensi bagi banyak proyek
    Saya juga memposting komentar yang sama di thread serangan rantai pasok SAP saat ini: https://news.ycombinator.com/item?id=47964003

    • Ini memang fenomena nyata. Per awal April, ada 7 kasus dalam 12 bulan terakhir, sedangkan selama 20 tahun sebelumnya ada 9: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
    • Orang-orang mendorong kode ke mana-mana dalam jumlah besar tanpa benar-benar meninjaunya dengan baik, jadi wajar kalau serangan rantai pasok ikut meningkat
    • Penyebabnya adalah pembaruan otomatis dan alat CI sudah mencapai tingkat adopsi kritis sehingga dipakai semua orang
      Dulu lebih sering orang menjalankan npm install secara manual, dan kemungkinan hanya saat build rusak atau sesekali saja
      Serangan rantai pasok bergantung pada orang, atau lebih tepatnya pipeline, yang mengautoupdate paket tanpa pikir panjang begitu rilis baru keluar
    • Secara historis, penanganan artefak dengan pemeriksaan keamanan tambahan adalah opsi enterprise berbayar, sedangkan pilihan yang kurang aman menjadi default karena jauh lebih praktis
      Saya tidak tahu apakah ini model bisnis yang bagus, dan kemungkinan besar tidak juga
    • left-pad bukan serangan, melainkan bug di NPM
      Seharusnya tidak boleh menghapus versi paket yang sudah dipakai paket publik lain, dan sebaliknya seharusnya boleh menghapus versi paket baru yang belum dipakai siapa pun
      Ketika pembuat left-pad berusaha menghapus semua datanya dengan niat meninggalkan layanan, NPM seharusnya mengembalikan kode error
      Menurut Wikipedia, ketika Koçulu kecewa dengan keputusan npm, Inc. dan tidak ingin tetap menjadi bagian dari platform itu, Schlueter selaku pembuat NPM memberikan perintah untuk menghapus 273 modul yang didaftarkannya

  • Hal yang aneh adalah ada 4 isu keamanan yang diajukan, dan semuanya otomatis dikomentari lalu ditutup oleh bot bernama pl-ghost [1][2][3][4]
    Pada akhirnya hanya [4] yang ditangani dengan benar, dan semua komentar bot itu dihapus
    Di laporan lain [5], komentar bot itu masih bisa dilihat, dan memberi informasi lebih banyak daripada sumber aslinya
    [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [5] https://socket.dev/blog/lightning-pypi-package-compromised

    • Saya Andy dari Lightning. Benar, kredensial PyPI dicuri melalui akun bot pl-ghost yang telah dikompromikan
      Penyerang membuat workflow Actions baru dengan akun itu, lalu dari workflow yang berjalan mereka mem-parsing dan mengekstrak secret PyPI
      Setelah merilis paket, mereka juga meninggalkan komentar dengan akun itu sambil sedikit mengejek kami

  • Semoga hari ketika tidak ada dependensi sama sekali cepat datang
    Sebagai contoh ekstrem, belakangan saat membuat aplikasi edukasi interaktif untuk putri saya, saya menyuruh Opus hanya memakai JavaScript dan HTML murni
    Dari pendulum ganda sampai simulasi fluida, semuanya berjalan baik sekaligus, dan dulu hal seperti ini akan melibatkan ratusan dependensi
    Jika kodenya berlisensi MIT, saya bisa menyuruh Opus mengekstrak hanya bagian yang benar-benar diperlukan lalu memodifikasi dan menyertakannya sesuai kebutuhan saya
    Untuk proyek hobi sejauh ini hasilnya bagus, dan ke depan saya berharap perangkat lunak produksi juga bisa tanpa dependensi

    • Kalau begitu Anda harus mengelola sendiri setiap perubahan dan banyak sekali pengecualian
      Kalau Chrome mengubah bentuk suatu API, Anda harus mencari dan memperbaikinya sendiri; kalau Maroko mengubah waktu mulai daylight saving, kode penanganan tanggal/waktu juga harus Anda update sendiri
      Hal-hal seperti itu selama ini terasa wajar karena pustaka yang mengurusnya untuk kita
      Untuk simulator pendulum ganda yang minggu depan mungkin sudah tidak menarik lagi bagi putri Anda, itu bukan masalah besar, tetapi bagi perusahaan yang membuat sesuatu yang harus terus berjalan tanpa batas, itu jadi masalah
    • Sekarang Anda justru terekspos ke dependensi yang benar-benar nyata, yaitu browser
    • Tentu Anda akan meninjau dengan teliti setiap baris kode yang dihasilkan Opus, seteliti standar yang Anda harapkan dari maintainer open source, kan? Kan?
      Mungkin saya harus merilis satu kode akses jarak jauh berlisensi MIT supaya masuk ke data pelatihan Opus
    • Saya lebih suka Rust daripada Go, jadi ini membuat saya galau. Bahkan dari sudut pandang LLM, Rust terasa lebih baik, tetapi filosofi dependensi Rust pada dasarnya seperti lubang hitam keamanan, dan Go jauh lebih baik
    • Ada repo atau forge yang bisa dibagikan? Saya punya game mengeja nama hewan ternak dan ingin memperluas pustaka saya serta mencari ide lain

  • Saat mengikuti kursus deep learning Fast.AI, saya kaget melihat banyaknya dependensi Python yang dibawa proyek machine learning
    Proyek frontend web memang selalu dianggap punya banyak dependensi pihak ketiga, tetapi bagi saya ekosistem machine learning tampak jauh lebih kusut
    Selain itu, pengembangan web selama ini dianggap sensitif terhadap keamanan sehingga sudah lama mengumpulkan banyak kebijaksanaan dan praktik keamanan, sedangkan pengembangan machine learning tampak jauh lebih ad hoc dan banyak praktik rekayasa perangkat lunak umum yang tidak diterapkan
    Misalnya, salah satu cara deployment model machine learning saat itu adalah Python pickle, yaitu objek executable tanpa batasan bawaan
    Model dalam format ini bisa melakukan apa saja pada komputer yang mengimpornya, dan ekosistem ala wild west semacam itu bisa membuat insiden keamanan dan serangan rantai pasok lebih mudah terjadi

    • Banyak orang di ekosistem itu pada awalnya memang bukan software engineer
      Sebagian belajar sedikit coding sambil jalan, sebagian adalah matematikawan, dan sebagian lagi pengembang yang sedang mabuk AI
      Ada juga pola pikir bahwa “kode tidak penting lagi, yang penting jalan”
      Bagi banyak orang, manajemen dependensi yang benar hanyalah pekerjaan remeh yang tidak ingin mereka pikirkan
      Dalam banyak proyek machine learning, semua faktor ini bercampur, padahal sebenarnya proyek machine learning justru termasuk bidang yang paling perlu fokus pada reproduksibilitas

  • Saya mencoba pencarian repo dan menemukan 2,2 ribu repo yang dibuat dalam sehari terakhir dengan teks "A Mini Shai-Hulud has Appeared": https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

    • Nama repo semuanya tampak berupa dua istilah/kata dari dune, misalnya harkonen, mentat, ornithoptor, dengan angka di belakangnya
      Ini tampak seperti tanda bahwa akun, mungkin token autentikasi GitHub/Actions, telah dikompromikan lalu dipakai untuk membuat repo
    • Akun https://github.com/tinin46 tampaknya menyimpan banyak key, tapi saya tidak begitu paham dipakai untuk apa
    • Saya tidak mengerti kenapa GitHub tidak langsung bertindak dan memblokir repo yang README-nya cocok dengan regex itu
      Ini pernah terjadi sebelumnya, jadi saya kira mereka sudah belajar
      Malware ini tampaknya tidak berusaha keras, dan Microsoft juga tampaknya tidak terlalu berusaha
    • Ini sebenarnya sedang terjadi apa?

  • Sebagai disclaimer, saya belum pernah memakai pytorch dan juga tidak terlalu paham praktik keamanan perangkat lunak
    Tetapi saya sulit membayangkan skenario di mana pytorch memerlukan akses jaringan
    Rasanya salah kalau modul mana pun bisa diimpor dari mana saja di codebase lalu memakai API itu
    Sepertinya perlu ada pembatasan import tambahan atau analisis statis
    Bahasa pemrogramannya tampaknya belum punya abstraksi yang tepat untuk menangani masalah seperti ini
    Sebagai perbandingan, saya suka bahwa di Rust kita bisa melihat mutability dan lifetime hanya dari signature fungsi, tanpa harus memahami kode internalnya
    Rasanya dependensi juga butuh sesuatu yang mirip
    Developer seharusnya bisa mengaudit semua dependensi dengan mudah tanpa harus mengintip kode level bawah, lalu langsung melihat “oh, dependensi ini memakai eval()” atau “yang ini mengakses jaringan”
    Aplikasi mobile memaksa permission, jadi rasanya developer juga seharusnya bisa membuat allowlist hanya untuk kemampuan tertentu alih-alih menerima seluruh tumpukan fitur begitu saja

    • Ekosistem Python mungkin tidak akan pernah mengizinkan hal seperti ini, tetapi saya berharap topik ini bisa lebih dipahami dan diakui di sana
      Saya tidak ingin terlalu menggeneralisasi, tetapi khususnya komunitas pengembangan AI tampaknya lebih memilih kenyamanan daripada semua pertimbangan lain
      Misalnya, sudah seperti standar bahwa sebuah proyek akan otomatis mengunduh model besar saat pertama kali dijalankan
      Biasanya itu bisa dimatikan, tetapi mencari parameter yang benar benar-benar menyakitkan karena lapisan class kode yang dalam di banyak pustaka
      Memang menyenangkan kalau hal-hal rumit, yang sering kali nyaris cuma mainan, bisa dimulai dengan sangat mudah, tetapi suasana permisif ini cukup membuat tidak nyaman
      Langkah pertama penyelesaian masalah rasanya selalu “pip install …”, dan beberapa lingkungan, misalnya MacOS, juga tidak terlalu baik dalam virtualisasi akses GPU
    • Ada kasus training model di banyak compute node. Itu adalah contoh besar yang memang membutuhkan akses jaringan

  • Minggu ini saya sempat bertanya-tanya apakah memakai uv untuk manajemen versi Python adalah ide yang bagus
    Di situs webnya [1] tertulis, “karena Python tidak menyediakan binary resmi untuk distribusi, uv memakai distribusi dari proyek Astral python-build-standalone”
    Itu menunjuk ke repo GitHub ini https://github.com/astral-sh/python-build-standalone, yang kemudian merujuk lagi ke https://gregoryszorc.com/docs/python-build-standalone/main/r...
    Kalau saya memahaminya dengan benar, sepertinya source code untuk build Python tidak diambil langsung dari python.org, dan saya tidak yakin seberapa aman itu
    Saya punya kekhawatiran yang sama terhadap asdf [2], tetapi asdf memakai pyenv [3] dan itu terasa sedikit lebih dekat ke jalur resmi
    Bisakah seseorang menjelaskan alat mana yang lebih baik dan lebih aman antara uv dan asdf untuk instalasi Python?
    [1] https://docs.astral.sh/uv/guides/install-python/
    [2] https://github.com/asdf-community/asdf-python
    [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

    • python-build-standalone mengambil source CPython langsung dari python.org[1]
      Memangnya mau ambil dari mana lagi?
      [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
    • Saya tidak terlalu khawatir tentang uv dan cpython. Prosesnya kokoh, responsnya cepat, dan sekarang dananya juga cukup besar
      Yang saya khawatirkan adalah formatter seperti mdformat, yang dipakai luas tetapi pada dasarnya dikelola satu orang di waktu luangnya, atau dependensi yang sangat spesifik yang sudah bertahun-tahun tidak diperbarui dan berada tiga tingkat di bawah dalam pohon dependensi
      Saya tidak ingin mem-pin semua pembaruan dan menyetujui manual semuanya pada aplikasi yang sedang aktif dikembangkan, tetapi untuk aplikasi serius itu mulai terasa seperti keharusan sekarang
      Sementara itu saya akan mengambil API key dari file .env yang tidak terenkripsi
      Kalau ini terjadi pada webapp konsumen besar, itu memalukan tapi masih bisa dimengerti; tetapi kehilangan ratusan sampai ribuan dolar gara-gara dependensi tidak langsung dari repo demo main-main yang kebetulan ada di host dan sistem yang sama itu terlalu menyakitkan
      Ada yang tahu apakah OAI atau Anthropic akan memberi refund jika key dicuri dengan cara seperti ini? Atau itu dianggap kesalahan pengguna?
    • Dari awal, uv sendiri adalah binary yang Anda jalankan di komputer untuk mengelola binary Python, paket, binary di dalamnya, alat sistem global, dan seterusnya
      Saya tidak tahu seberapa besar perbedaan risikonya antara Python binary yang mereka build sendiri dengan yang dibangun orang lain

  • Belakangan ini sebagian besar pip install saya terjadi karena Claude Code yang menyarankan lalu saya tinggal menekan Enter
    Model itu dilatih dengan data beberapa bulan lalu, jadi jelas tidak mungkin tahu apa yang dikompromikan minggu ini
    Saya sadar saya telah membuat filter terburuk untuk menilai “apakah paket ini aman saat ini”

    • Jangan menyalahkan LLM atas kemalasan dan kurangnya due diligence
    • Filter yang mana?
      Anda bilang Claude Code merekomendasikan software untuk diinstal dari internet, lalu Anda langsung menginstalnya
      Saya belum pernah mendengar ada yang menyarankan Claude Code atau LLM mana pun sebagai filter untuk menilai “apakah paket ini aman saat ini”, dan dengan alasan yang Anda sebut sendiri, itu terdengar seperti heuristik yang sangat buruk
    • Data pelatihan yang usang memang sebagian masalahnya, tetapi bahkan model terbaru pun tidak bisa tahu apa yang akan dijalankan setup.py di mesin saya
      Karena memang tidak ada yang benar-benar memeriksa paket itu sebelum dijalankan
      Yang dibutuhkan adalah alat yang mengambil metadata sebelum eksekusi untuk memeriksa hook apa saja yang ada
    • Ini mudah dihindari kalau Anda tidak menekan Enter
    • Yang dimaksud “filter terburuk” itu kebiasaan menekan Enter begitu saja karena Claude yang menyuruh?

  • Claude Code diperbarui hampir setiap hari, kadang bahkan beberapa kali sehari
    Kalau suatu hari Anthropic dikompromikan, kita semua bakal kena parah

    • “Kita” itu siapa?
    • Kalau dijalankan dalam VM/kontainer tanpa privilege dan dengan akses jaringan terbatas, tidak juga
      Tapi akhir-akhir ini semua orang serba YOLO
    • Rasanya itu sudah tercermin dalam harga Polymarket

  • Saya melihat pesan ini di GitHub yang diposting pada 20 April dan agak bingung
    "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
    Kalau mereka sudah tahu soal masalahnya sejak saat itu dan masih belum memberi peringatan sampai sekarang, saya akan sangat tidak suka
    Saya berharap ada orang yang tahu lebih banyak dan bisa menjelaskan dengan jelas
    https://github.com/Lightning-AI/pytorch-lightning/issues/216...

    • Saya Andy dari Lightning. Paket berbahaya itu dipublikasikan ke PyPI hari ini pada 12:45 PM UTC
      Sebelum itu tidak ada distribusi terdampak, dan kami juga belum mengetahui kebocorannya
      Rilis asli di GitHub tidak bermasalah, tetapi kami tetap menurunkannya untuk mencegah kebingungan
    • Untuk pengguna uv: https://docs.astral.sh/uv/reference/settings/#exclude-newer