Agen SSH VSCode itu Absurd

• Fly.io mencoba masuk ke dalam alur pengeditan jarak jauh SSH VSCode, lalu mendapati bahwa alih-alih memanfaatkan shell jarak jauh secara ringan, VSCode memakai struktur yang memasang dan menjalankan agen terpisah
• Pembuatan kode oleh LLM lebih berguna dalam loop agen yang terhubung ke lingkungan eksekusi, tetapi karena dapat sampai mengutak-atik pengaturan sistem di laptop pengembangan, diperlukan instans Linux yang terisolasi
• Tramp di Emacs memperluas fungsinya ke lingkungan jarak jauh dengan menjalankan perintah Bourne shell di lingkungan interaktif seperti SSH, sedangkan VSCode mengunduh agen dan binary Node lewat stager berupa snippet Bash
• Agen VSCode berjalan di atas SSH yang di-port-forward, lalu membuat koneksi WebSockets ke frontend VSCode, sehingga dapat menjelajahi file, mengedit file sewenang-wenang, menjalankan shell PTY, dan mempertahankan dirinya sendiri
• Mengizinkan pengeditan jarak jauh VSCode di server pengembangan saja sudah berat; jika cara seperti ini dipakai saat insiden produksi, kekhawatirannya lebih besar, tetapi untuk koneksi kustom ke Fly Machine struktur ini bisa dihindari

---

Isolasi yang dibutuhkan untuk loop agen LLM

• Fly.io tertarik untuk berintegrasi dengan alur VSCode melakukan pengeditan jarak jauh lewat SSH
  • Karena pengguna VSCode banyak, terutama karena fork VSCode yang menghasilkan kode dengan LLM sedang digunakan
• Kode yang dihasilkan LLM berguna ketika ia tahu apa yang sedang dilakukan pengguna, dan menjadi lebih efektif jika loop-nya dapat ditutup dengan lingkungan eksekusi
  • LLM menghasilkan kode
  • Scaffolding agen menjalankan kode
  • Kode menghasilkan error
  • Agen meneruskan error itu kembali ke LLM
  • Proses ini berulang
• Struktur ini bisa menjadi penawar yang setengah efektif terhadap halusinasi, tetapi berbahaya jika dijalankan begitu saja di laptop pengembangan
  • LLM dapat berulang kali mengutak-atik bukan hanya proyek Git yang sedang dikerjakan, tetapi juga pengaturan sistem
• Bentuk yang lebih baik adalah menjalankan konfigurasi agen closed-loop pada instans Linux bersih yang langsung menyala, serta mencegah lingkungan tersebut merugikan pengguna

Cara kerja agen SSH jarak jauh VSCode

• Tramp di Emacs adalah kode Elisp yang nyaris menjadi leluhur spiritual sistem pengeditan jarak jauh
  • Jika terhubung ke lingkungan interaktif yang dapat menjalankan perintah Bourne shell, seperti sesi SSH, ia memperluas fungsi Emacs ke lingkungan tersebut
• VSCode juga memiliki fitur yang mirip Tramp, tetapi strukturnya bukan sekadar Tramp yang disederhanakan lalu dipindahkan ke TypeScript
• Alih-alih hanya memakai alat yang sudah ada pada koneksi jarak jauh, VSCode menjalankan stager snippet Bash untuk mengunduh agen
  • Agen ini menyertakan instalasi binary Node
  • Lokasi yang tampak sebagai source terkait adalah direktori server/node di microsoft/vscode
• Agen berjalan di atas SSH yang di-port-forward, dan membuat koneksi WebSockets ke frontend VSCode yang sedang berjalan
  • Subprotokolnya dapat menelusuri filesystem
  • Dapat mengedit file sewenang-wenang
  • Dapat menjalankan proses shell PTY miliknya sendiri
  • Dapat membuat dirinya sendiri tetap bertahan
• Ada istilah yang dipakai industri keamanan untuk alat yang bekerja seperti ini, tetapi tidak disebutkan langsung karena dianggap tidak adil bagi VSCode
• Mengizinkan pengeditan jarak jauh VSCode di server pengembangan terasa mengkhawatirkan, dan jika cara yang sama dipakai saat insiden produksi, kekhawatirannya makin besar
• Saat membuat koneksi kustom ke Fly Machine, struktur ini tidak perlu dipedulikan, sehingga dalam arti yang mendalam ini dianggap bukan masalah penting

[GN⁺]

Pendapat di Hacker News

• Awalnya ingin menulis artikel panjang selama sekitar sebulan tentang perangkat lunak yang telah diutak-atik selama 3–4 tahun, tetapi Kurt menjadi gelisah karena sejak Agustus tidak ada apa pun yang diunggah ke blog, jadi akhirnya memutuskan menulis artikel yang paling sederhana
  Pendekatannya adalah melakukan kebalikan dari yang selama ini dilakukan: menulis artikel berupaya rendah, dan mengira satu artikel bisa selesai dalam 30 menit. Ini hanya menuliskan sesuatu yang sedang diutak-atik, dan mungkin penulisnya memikirkannya lebih sedikit daripada pembacanya

  • Setelah membaca artikelnya, baru sekarang paham bahwa strukturnya memang tidak masuk akal, tetapi dari artikel blog saja hal itu tidak langsung terasa. Ketika melihat daftar hal-hal yang bisa dilakukan agen, saya sudah berasumsi bahwa arahnya tidak mungkin seperti itu
    Kalimat di README, “A compromised remote could use the VS Code Remote connection to execute code on your local machine.” jauh lebih jelas, dan rasanya harus ada nomor CVE di sebelah peringatan keamanan ini
  • Paragraf pertama komentar HN itu mungkin akan lebih enak dibaca kalau tidak ada satu pun titik. Senang melihat blog favorit masih hidup, karena sempat agak khawatir
    Dua artikel pertama yang terlihat saat ini—tulisan McCord-Valim tentang FLAME-Livebook-GPU dan tulisan ini yang memuat “murid”—benar-benar menunjukkan lintasan psikologis seorang developer
  • Semoga lebih banyak artikel berupaya rendah seperti ini diunggah
  • Masalahnya mungkin ada pada ssh. Saat terhubung lewat ssh, sepertinya perlu ada cara untuk meminta pengalaman seperti Docker, dan akan bagus jika bisa menetapkan agar API yang dipakai memblokir proses atau akses sistem berkas di luar folder tertentu
    Bisa saja mengizinkan binary sistem, tetapi itu menjadi rumit dan VSCode mungkin harus mendorong lebih banyak hal ke klien. Dari pencarian sekilas, ada opsi chroot di sisi server ssh, tetapi di manual klien ssh tidak banyak disebutkan
    Atau mungkin solusinya adalah mengunduh container Docker di remote, menjalankan container yang me-mount direktori remote, lalu masuk ke container itu lewat ssh
    Masalah dengan pendekatan yang hanya menyinkronkan file subdirektori adalah VSCode juga memerlukan eksekusi remote dan debugging yang dimulai olehnya. Karena itu plugin juga perlu akses remote atau harus dijalankan di remote, dan untuk sebagian pengamatan kode, jika dijalankan secara lokal, biaya pra-sinkronisasi seluruh subdirektori bisa terlalu besar
  • Cara “kami memutuskan untuk kembali menjadi blog saja. Jadi kami harus mempelajari ini, dan sekarang Anda juga harus mempelajarinya” memang jalan yang benar

• Mungkin terdengar naif, tetapi saya kurang paham mengapa ini menjadi masalah keamanan. Jika bisa ssh ke suatu mesin dan melakukan penerusan port socket, berarti pada dasarnya sudah punya izin untuk melakukan semua hal lain juga, dan protokol VSCode tampak hanya mengekspos itu dengan cara yang nyaman bagi mereka
  Saya penasaran apakah alasannya menjadi masalah keamanan adalah karena seseorang yang berada di jaringan yang sama dengan mesin remote tetapi tidak punya izin SSH bisa terhubung ke port yang diteruskan melalui SSH. Dari sisi pengguna, sistem SSH VSCode bekerja cukup baik dan saya menyukainya

  • Perbedaannya adalah apa yang dilakukan VSCode bukanlah sesi SSH yang didapat dengan perintah ssh atau PuTTY
    VSCode memasang agen remote di mesin target, memakai ssh sebagai protokol transport, lalu mengatakan akan membagikan jalur transport itu dengan pengguna. Jika hanya melakukan hal yang diinginkan, tidak masalah, tetapi sistem berbasis agen yang mengekspos API arbitrer menciptakan permukaan serangan dan risiko yang jauh lebih besar daripada cara yang familier namun tetap rumit, yaitu meniru terminal di atas ssh
  • Intinya adalah agen berjalan di atas SSH yang port-nya diteruskan, lalu membuat koneksi WebSocket ke frontend VSCode yang sedang berjalan
    Protokol di atas koneksi itu bisa menjelajahi sistem berkas, mengedit file arbitrer, meluncurkan proses PTY shell miliknya sendiri, dan mempertahankan dirinya. Fakta bahwa klien melakukan ssh ke server remote tidak berarti server tersebut dapat menjalankan kode arbitrer di klien; setidaknya klien harus melakukan suatu tindakan secara eksplisit
  • Pada dasarnya itu benar. Ini bukan kerentanan intrinsik atau masalah menembus batas keamanan
    Namun ini adalah masalah keamanan dalam arti yang sama seperti “curl | bash” adalah masalah keamanan. Analogi yang lebih dekat mungkin curl | bash di dalam bashrc
  • Agen di server pengembangan kini menjadi vektor balik menuju VS Code di laptop
    Karena agen terhubung ke jaringan dan selalu berjalan, lubang di firewall server pengembangan menjadi lubang di firewall laptop
  • Tentu saja izinnya memang sudah ada. Masalahnya, kini agen pihak ketiga dapat menggunakan izin itu sesukanya, dan pengguna mungkin tidak menyadarinya

• Semakin tahu bagaimana VSCode bekerja, semakin tampak seperti sesuatu yang nyaris disatukan dengan lakban dan ide-ide paling terkutuk yang mungkin terpikir oleh developer JavaScript
  Lihat saja ekstensi SSH: ada dua format URI ruang kerja. Yang satu pada dasarnya hanya berisi hostname, dan yang lain berupa dokumen JSON yang dienkode dalam heksadesimal; yang terakhir dipakai ketika perlu informasi tambahan seperti nama pengguna tertentu atau ketika hostname mengandung huruf kapital
  Alasan ini benar-benar diperlukan adalah karena entah mengapa, saat disimpan ke ruang kerja terbaru, hostname diubah menjadi huruf kecil
  Koneksi SSH juga mendukung konfigurasi ekstensi yang akan dipasang di server, tetapi jika terlalu banyak dimasukkan, koneksi ke host Windows gagal. Itu dikirim sebagai argumen command line melalui CMD, sementara CMD memiliki batas 8191 karakter, dan melalui CMD itu mereka memanggil PowerShell

  • VS Code lebih baik daripada Eclipse. Saya tidak pernah membutuhkan SSH lewat IDE, jadi tidak tahu soal bagian itu; biasanya saya ssh dengan PuTTY, lalu kalau perlu bekerja di server saya memakai Vi
  • Kalau tahu JavaScript/TypeScript, sangat mudah menambahkan dukungan bahasa khusus atau alat ke editor, dan itu bagus
    Bisa menyediakan autocompletion khusus, diagnostic, dan sebagainya, serta membuat Go to definition khusus untuk dukungan lintas bahasa
  • Ada beberapa baris yang paling menyedihkan dan langsung membuat saya terpikir “seperti ditempel lakban”: https://github.com/microsoft/vscode/blob/6dbde2a3ed308f88164...
    Semoga Microsoft mau mempekerjakan saya selama beberapa bulan, menaruh saya di pojokan, dan membiarkan saya mengurai kekacauan ini
  • Karena rasanya seperti barang yang dirangkai dari sampah dan tali, saya kembali lagi ke vim

• Saya pernah mengoperasikan server kelas untuk jaringan, eksploit biner, dan pemrograman sistem pengantar, dan benda ini benar-benar jadi sumber masalah besar. Karena trojan akses jarak jauh bodoh ini, mahasiswa tidak memahami cara memakai klien OpenSSH
  Saya mencoba beberapa hal untuk memperbaikinya. Di motd server kelas, saya menulis agar tidak memakai plugin server jarak jauh VSCode, dan di depan kelas saya menjalankan ncdu /home untuk menunjukkan bahwa mahasiswa yang penggunaan disk servernya melebihi 100MB, tanpa kecuali, adalah pengguna VSCode
  Saya juga membatasi proses pengguna menjadi 45, karena entah bagaimana trojan akses jarak jauh VSCode memakai sekitar 50 proses Node. Jika mahasiswa mengabaikan motd dan peringatan saat kuliah, mereka kena batas itu, lalu harus meminta kami mematikan proses agar bisa terhubung lagi
  Pada akhirnya, alih-alih batas proses, saya menggantinya dengan skrip yang setiap 10 detik membunuh semua trojan akses jarak jauh .vscode-server

  • Ini banyak mengingatkan saya pada masa kuliah, ketika saya mengakali pembatasan kuno yang kelewat ketat yang dipasang admin sistem kampus di jaringan
  • Ini bukan hanya terjadi karena VSCode populer. Bahkan lebih dari 10 tahun lalu saat kuliah, ada mahasiswa yang memakai Sublime dengan plugin SFTP, atau menulis kode secara lokal lalu memindahkan file dengan klien GUI seperti FileZilla
    Di kelas tempat saya menjadi asisten dosen, ada tugas memproses kode mesin dasar untuk meniru alat perakitan dan eksekusi ISA yang dipelajari, dan mahasiswa harus memahami struktur byte file dengan alat seperti hexdump
    Namun Sublime “dengan baik hati” merender file objek seolah-olah seperti representasi teks hexdump, menambahkan spasi demi keterbacaan, dan menampilkannya dalam urutan endian yang berbeda dari ketika menjalankan hexdump di server Linux kampus
    Setiap semester, beberapa mahasiswa datang bertanya mengapa kode yang mereka tulis untuk membaca string ASCII seperti AD DE EF BE malah mencari teks yang tidak mereka kenali; ternyata mereka belum memastikan bahwa nilai byte sebenarnya dimulai dengan 0xDE, 0xAD, 0xBE, 0xEF
  • Saya penasaran kenapa harus sampai sejauh itu. Saya tahu banyak upaya dicurahkan untuk memblokir VSCode, tetapi tidak jelas apa persisnya yang ditimbulkan VSCode
  • 50 proses Node, ya ampun, tiap hari kita makin jauh dari Tuhan
  • Kalau Anda penasaran “murid” di sini merujuk pada apa dan baru pertama kali mendengar RAT, RAT adalah singkatan dari Remote Access Trojan

• Saya kurang tahu apa alternatifnya di sini. Penyuntingan lewat SSH di VSCode bekerja luar biasa baik, dan saya sudah lama berhenti mengutak-atik vim, nano, atau micro di mesin jarak jauh
  Agennya membiarkan saya bekerja dengan tenang tanpa mengganggu. Rasanya hampir seperti bekerja di mesin lokal, dan menurut saya itu keunggulan besar
  Ini bisa jadi risiko keamanan, tetapi pengalaman pengembangannya tidak ada tandingannya. Saya tidak terlalu peduli editor lain apa yang dibunuh VSCode; yang penting alatnya membiarkan saya bekerja tanpa menghalangi

  • Alternatifnya lebih dekat dengan pendekatan yang diusulkan TRAMP. Sepengetahuan saya, TRAMP memperlakukan remote seperti sistem berkas jaringan, bukan sebagai host eksekusi
    Ia tidak menyebarkan biner, membaca dan menulis byte lewat pipe, dan semua eksekusi yang bermakna terjadi secara lokal. Khususnya, ia tidak membuat persistensi; “plugin VSCode bisa diakses selama terhubung lewat SSH” berbeda dengan “plugin VSCode bisa diakses selamanya”
  • Risiko keamanannya muncul karena plugin yang tidak terverifikasi memiliki akses tak terbatas ke editor
  • Dari yang saya lihat, rekan-rekan yang memakai VSCode dibatasi dengan cara yang tidak mereka sadari, dan tidak punya gambaran tentang seberapa baik cara yang lebih baik bisa bekerja
    Saat bekerja di beberapa remote, mereka sering tidak tahu sedang terhubung ke mana atau bagaimana status koneksinya. Terminal lambat dan persistensi status sesi tidak konsisten
    Pengalamannya jauh lebih buruk daripada memakai tmux dan editor teks yang layak. Selain itu, servernya sangat berat dan tidak tertutup dengan benar, sehingga lazim ada enam instance server yang berjalan sekaligus
    Separuh pembaruan rusak, dan mereka bisa membuang satu jam karena tidak tahu cara masuk ke host dengan klien ssh sungguhan untuk membersihkan server vscode yang rusak
  • Saya tidak tahu persis fitur apa yang disediakan VSCode, tetapi untuk beberapa pekerjaan penyuntingan jarak jauh, sshfs cukup cocok. Pada dasarnya seharusnya mirip dengan VSCode
  • TRAMP di Emacs juga cukup buruk, tetapi tetap lebih stabil dan ramah pengguna dibanding kekacauan bernama penyuntingan jarak jauh VSCode

• Apa yang kita pelajari? Bahwa remote code execution itu ada? Bahwa kepercayaan yang salah tempat pada alat pengembangan sering berujung penyesalan? Bahwa desain perangkat lunak modern berantakan? Semua itu sudah jelas kalau saja sedikit lebih berhati-hati
  SSH adalah solusi dari era 90-an. Ia Telnet yang diberi beberapa fitur tambahan, dan meski disebut shell “secure”, secara harfiah kurang aman daripada Telnet+TLS
  Karena sudah ada tunnel dengan sesi pengguna di server, orang-orang memutuskan tidak perlu membuat transport jaringan untuk aplikasi dan protokol koneksi aman secara terpisah, lalu menumpuk segala macam hal aneh tetapi dipuji-puji di atas SSH
  Ini hasil dari membuang konsep yang dipelajari dari sistem operasi terdistribusi, mengabaikan autentikasi dan otorisasi tingkat lanjut yang sudah dikembangkan, lalu menerima hal yang paling buruk dan paling mudah
  “SSH agent” seperti ini bukan sesuatu yang tidak masuk akal. Kita tidak bergerak untuk membuat alat yang tepat untuk pekerjaan yang tepat, jadi kita terus memasukkan lebih banyak hal ke alat lama yang sebenarnya tidak dirancang untuk tujuan itu. Kita tidak berhak pura-pura terkejut
  Inilah dunia yang kita buat. Kita semua membuatnya, entah lewat kerja kita maupun lewat persetujuan diam-diam. Bukan hanya SSH; hal yang sama terjadi dalam politik, bisnis, sekolah, dan yang lainnya. Setiap hari kita hidup di tumpukan yang kita bangun sendiri, dan setiap hari ketika kita tidak melakukan apa-apa, kita menambahkan satu sekop lagi. Kalau kita sendiri memegang sekopnya, kita tidak bisa pura-pura ini mengejutkan atau gila

  • Yang membuat ini bukan developer, melainkan orang-orang keamanan jaringan. Jika semua port keluar selain HTTPS dan ssh diblokir, maka setelah itu semuanya mau tidak mau harus ditunnel lewat HTTPS atau ssh
    Jadi secara umum, jika koneksi HTTPS keluar diizinkan, lebih masuk akal untuk mengizinkan juga semua koneksi keluar selain SMTP. Trafik berbahaya yang sebenarnya toh akan ditunnel lewat HTTPS, dan satu-satunya efek yang tersisa hanyalah menghambat penerapan protokol baru yang tidak harus menanggung kompleksitas dan inefisiensi tunnel
  • Sebaliknya, menurut saya autentikasi key pair SSH dan sertifikat adalah metode autentikasi terbaik yang saya tahu. Ia juga terintegrasi dengan FIDO2 tanpa konfigurasi awal
    Saya berharap login web lebih mirip dengan cara SSH melakukannya
  • Ini terdengar sangat seperti teori konspirasi. Tidak semua hal di dunia berjalan karena niat jahat; kebanyakan adalah orang-orang yang mencoba hal terbaik yang bisa mereka pikirkan di bawah tekanan
    Sesekali keluar dan menyentuh rumput itu baik untuk jiwa. Dan saya juga berharap ada usulan bagaimana membuat protokol SSH yang lebih baik. Keluhan tanpa kritik yang konstruktif tidak banyak gunanya

• Istilah “SSH agent” di sini membingungkan. Biasanya itu berarti daemon yang melakukan cache token autentikasi

  • Benar. VSCode tidak menyediakan SSH Agent; ia berkomunikasi dengan SSH Agent lokal. Pada dasarnya ini versi ForwardAgent miliknya sendiri, beserta implikasi keamanannya
    Selain itu, cara tersebut merusak SSH agent macOS yang terkenal: https://github.com/maxgoedjen/secretive/issues/543
  • Karena ada “VSCode” di depan “SSH Agent”, menurut saya pembedaan itu cukup jelas

• Saya sepenuhnya setuju bahwa memakai vscode remote di server produksi itu gila
  Namun fitur-fitur lain yang digambarkan sebagai “tidak masuk akal” terdengar seperti fitur yang memang bisa diharapkan

  • Kalau mempertimbangkan implikasi keamanannya, saya penasaran apa use case fitur ini. Mungkin sebatas instance staging yang cukup terisolasi dari lingkungan lain

• Saya sudah sampai menjadi staff engineer di MAANG, dan menurut saya ini level yang sulit dicapai hanya dengan Vim biasa. Namun saya melihat high performer lain juga masih cenderung memakai Vim atau Emacs
  Ada banyak developer hebat yang memakai VCode, JetBrains, dan sebagainya, tetapi menurut saya kecenderungan untuk mencari hambatan masuk, membongkar “keajaiban” alat lewat eksplorasi, serta menghargai proyek yang sepenuhnya open source dan sangat bisa diutak-atik serta digerakkan komunitas, lebih menjelaskan fenomena ini daripada fitur atau kemudahan penggunaan
  Membaca betapa rumitnya remote editing di VSCode justru membuat saya makin tidak ingin memakai VSCode. Cukup ssh ke mesin tersebut dan pakai editor yang ada di mesin itu
  Solusi VSCode memang berjalan, tetapi tidak elegan, tidak bisa diterapkan secara universal, dan lebih mudah rusak. Dan maaf untuk pengguna Emacs, tetapi Tramp masih cukup mengerikan, dan netrw juga tidak lebih baik

  • Saya setuju Tramp tidak hebat, tetapi ada solusi sederhana yang bekerja lebih baik: watchexec + rsync
    Anda bisa memantau path file tertentu dan menyinkronkan persis hanya yang diperlukan. Karena tetap bekerja di sistem file lokal, tidak ada lag saat mengedit, semua alat lokal bisa dipakai, dan sinkronisasi selesai dalam hitungan milidetik
    File yang dihapus secara lokal juga bisa dibuat terhapus di remote, dan setelah selesai bekerja di mesin remote, salinan lokal selalu tetap ada. Di Tramp, bagian ini selalu harus disinkronkan secara manual. Selain itu, ini tidak bergantung pada editor
    Fitur VS Code yang ini membuat saya gelisah, sekarang setelah saya benar-benar tahu apa yang dilakukannya
  • Setelah bergabung dengan tim baru yang berpusat pada VSCode, saya jadi banyak memikirkan kenapa saya masih lebih suka vim. Pengamatan terbaru saya adalah toolbar dan elemen lain yang memenuhi layar terlalu berisik secara visual
    Saat saya menyalakan Copilot, toolbar bertambah lagi, dan teks terbang masuk ke tempat yang hendak saya gunakan. Vim membiarkan saya sekadar melihat kode, berpikir, dan menulis. Dengan VSCode, sulit masuk ke flow state
    Usia saya pertengahan 30-an; saat kuliah saya memakai emacs, lalu beralih ke vim di pekerjaan pertama. Untuk proyek Java yang sangat rumit saya memakai IntelliJ, tetapi selain itu saya terus memakai vim
  • Saat coding sebagai hobi, saya suka mengeksplorasi alat dan membongkar keajaibannya. Sekarang setelah menjadi pekerjaan, saya suka VSCode. Tidak perlu banyak mengutak-atik, jadi saya bisa fokus menyelesaikan pekerjaan
    Saya hanya sesekali membuka vim ketika perlu melakukan pengolahan regex yang kompleks
  • Principal engineer dan distinguished engineer di tim kami memakai Vim dan Emacs

• Alih-alih bekerja bersama alat remote yang sudah ada, VSCode menerapkan agen menyeluruh yang mencakup instalasi binary Node.js, koneksi WebSocket yang kembali ke frontend VSCode, serta kemampuan akses sistem yang luas
  Agen VSCode ini memiliki hak akses luas, termasuk menjelajahi sistem file, mengedit file, membuat proses shell PTY, bahkan kemampuan mempertahankan dirinya sendiri

  • Tidak terlihat alternatif yang masuk akal untuk mendukung hal-hal yang dilakukan VSCode, seperti menjalankan ekstensi yang tidak terpasang secara lokal. Anda mungkin tidak menginginkan fitur seperti itu, tetapi itu adalah bagian dari rangkaian fitur produk
  • Tidak jelas apakah masalah ini ada pada instance VS Code lokal atau instance remote
    Jika remote, saya paham bahwa elisp Tramp lebih ringan dari sisi dependensi, tetapi saya bertanya-tanya apakah permukaan serangannya benar-benar begitu berbeda. Dengan kata lain, saya tidak tahu apakah binary Node remote memiliki hak akses yang tidak dimiliki pengguna yang menjalankan perintah ssh arbitrer
    Jika tujuan awalnya adalah memberikan semua kunci mesin virtual sementara yang bisa dibuang kepada LLM, saya bertanya-tanya apakah soket yang dibuka agen itu berarti mesin pengembang yang tadinya ingin diisolasi juga bisa tersentuh
  • Dari satu sudut pandang, hal-hal seperti ini semestinya disediakan sistem operasi modern sebagai fitur standar, dan VSCode bisa dilihat sedang mencari jalan memutar karena fitur seperti itu tidak ada
    Ini mungkin terdengar gila, tetapi kernel itu sendiri bisa menyediakan web server atau protokol lain dengan enkripsi dan autentikasi, lalu memungkinkan kontrol langsung atas seluruh mesin melalui eBPF. Ini bisa menjadi paradigma yang sama sekali berbeda untuk kendali jarak jauh klien/server
    Tentu saja, itu juga bisa menjadi celah keamanan yang cukup besar untuk dilewati Death Star