VSCode’un SSH aracısı akıl almaz

• Fly.io, VSCode uzaktan SSH düzenleme akışına entegre olmaya çalışırken VSCode’un uzak kabuğu hafifçe kullanmak yerine ayrı bir aracı kurup çalıştıran bir yapıda olduğunu gördü
• LLM ile kod üretimi, çalışma ortamına bağlı bir aracı döngüsünde daha yararlı olsa da geliştirme dizüstüsünün sistem ayarlarına kadar müdahale edebileceği için yalıtılmış bir Linux instance’ı gerekir
• Emacs’in Tramp’i, SSH gibi etkileşimli ortamlarda Bourne shell komutları çalıştırarak işlevlerini uzak ortama genişletir; VSCode ise aracıyı ve Node ikili dosyasını indirmek için Bash parçacığı biçiminde bir stager kullanır
• VSCode aracısı, port yönlendirmeli SSH üzerinde çalışır ve VSCode önyüzüyle WebSockets bağlantısı kurarak dosya gezme, rastgele dosya düzenleme, shell PTY çalıştırma ve kendini kalıcı kılma işlemleri yapabilir
• Geliştirme sunucusunda VSCode ile uzaktan düzenlemeye izin vermek bile büyük bir yük getirir; üretim ortamındaki bir olay sırasında bu yöntem kullanılırsa endişe daha da artar, ancak Fly Machine için özel bağlantıda bu yapıdan kaçınmak mümkün oldu

---

LLM aracı döngüsü için gerekli yalıtım

• Fly.io, VSCode’un SSH üzerinden uzaktan düzenleme yaptığı akışa entegre olmakla ilgilendi
  • Çünkü VSCode kullanıcıları çok fazla ve özellikle LLM ile kod üreten VSCode fork’ları kullanılıyor
• LLM’in ürettiği kod, kullanıcının ne yaptığını bildiğinde yararlıdır; çalışma ortamıyla döngüyü kapatabildiğinde etkisi daha da artar
  • LLM kod üretir
  • Aracı iskeleti kodu çalıştırır
  • Kod hata üretir
  • Aracı hatayı tekrar LLM’e iletir
  • Bu süreç tekrarlanır
• Bu yapı, halüsinasyonlara karşı yarı etkili bir panzehir olabilir; ancak geliştirme dizüstüsünde olduğu gibi çalıştırmak risklidir
  • LLM yalnızca üzerinde çalışılan Git projesine değil, sistem ayarlarına da tekrar tekrar dokunabilir
• Daha iyi biçim, anında ayağa kalkan temiz bir Linux instance’ında kapalı döngü tipi aracı yapılandırması çalıştırmak ve bu ortamın kullanıcıya zarar vermesini engellemektir

VSCode uzaktan SSH aracısının çalışma biçimi

• Emacs’in Tramp’i, uzaktan düzenleme sistemlerinin düşünsel atası sayılabilecek Elisp kodudur
  • SSH oturumu gibi Bourne shell komutları çalıştırabilen etkileşimli bir ortama bağlandığında Emacs işlevlerini o ortama genişletir
• VSCode’da da Tramp’e benzer bir özellik vardır; ancak bu, basitleştirilmiş Tramp’in TypeScript’e taşınmış hali değildir
• Uzak bağlantıda yalnızca mevcut araçları kullanmak yerine VSCode, aracıyı indirmek için bir Bash parçacığı stager’ı çalıştırır
  • Bu aracının içinde Node’un ikili kurulum paketi bulunur
  • İlgili kaynak gibi görünen yer microsoft/vscode’daki server/node dizini
• Aracı, port yönlendirmeli SSH üzerinde çalışır ve çalışan VSCode önyüzüne WebSockets bağlantısı oluşturur
  • Alt protokol dosya sisteminde gezinebilir
  • Rastgele dosya düzenlemek mümkündür
  • Kendi shell PTY sürecini çalıştırabilir
  • Kendini kalıcı hale getirebilir
• Güvenlik sektöründe bu şekilde çalışan araçlar için kullanılan bir ad vardır; ancak VSCode’a haksızlık olacağı için doğrudan söylenmiyor
• Geliştirme sunucusunda VSCode ile uzaktan düzenlemeye izin vermek huzursuz edicidir; üretim ortamındaki bir olay sırasında aynı yöntem kullanılırsa endişe daha da artar
• Fly Machine’e özel bağlantı yapılırken bu yapıyı dert etmek gerekmedi; bu yüzden derin anlamda önemli bir sorun olmadığı düşünülüyor

[GN⁺]

Hacker News yorumları

• 3-4 yıldır kurcaladığı yazılım hakkında yaklaşık bir ay boyunca uzun bir yazı yazmaya çalışıyordu; ancak Kurt, bloga ağustostan beri hiçbir şey koymadığı için huzursuzlanınca sonunda en basit yazıyı yazmaya karar verdi.
  O zamana kadar yaptığının tersine düşük eforlu bir yazı yazalım tarzındaydı ve 30 dakikada bir tane çıkarabileceğini düşündü. Bu, sadece kurcaladığı şeyi yazıya dökmesinden ibaretti ve muhtemelen okuyanlardan daha az kafa yormuştu.

  • Yazıyı görünce bunun ne kadar saçma bir yapı olduğunu ancak şimdi anladım, ama blog yazısı tek başına hemen kafama yatmadı. Ajanın yapabildiklerini sıraladığında, böyle bir yönde olamayacağını varsayıvermiştim.
    README’deki “Tehlikeye düşmüş bir uzak makine, yerel makinenizde kod çalıştırmak için VS Code Remote bağlantısını kullanabilir.” cümlesi çok daha açıktı ve bu güvenlik uyarısının yanında bir CVE numarası olması gerekiyormuş gibi duruyor.
  • HN yorumunun ilk paragrafı hiç nokta olmasaydı sanki daha iyi okunurdu. Sevdiğim bir blogun hâlâ hayatta olduğunu görmek güzel; hafiften endişelenmeye başlamıştım.
    Şu anda görünen ilk iki yazı, McCord-Valim’in FLAME-Livebook-GPU yazısı ile içinde “murid” geçen bu yazı, bir geliştiricinin psikolojik seyrini gerçekten iyi gösteriyor.
  • Daha çok düşük eforlu yazı paylaşsa keşke.
  • Sorun ssh de olabilir. ssh ile bağlanırken Docker benzeri bir deneyim istemenin bir yolu olmalı gibi; belirli bir klasör dışındaki süreçleri ya da dosya sistemi erişimini engelleyen bir API kullanmasını belirtebilsek iyi olurdu.
    Sistem ikililerine izin verilebilir, ama bu karmaşıklaşır ve VSCode’un istemciye daha fazla şey itmesini gerektirebilir. Üstünkörü bakınca ssh sunucusu tarafında chroot seçenekleri görünüyor, ama ssh istemci kılavuzunda pek bir şey yok.
    Ya da çözüm, uzakta bir Docker konteyneri indirip uzak dizini bağlayan bir konteyner çalıştırmak ve sonra o konteynere ssh ile bağlanmak olabilir.
    Yalnızca alt dizindeki dosyaları senkronize etme yaklaşımının sorunu, VSCode’un başlattığı uzak çalıştırma ve hata ayıklamaya da ihtiyaç duyulması. Bu yüzden eklentilerin de uzak erişime ihtiyacı var ya da uzakta çalışmaları gerekiyor; bazı kod gözlemlerini yerelde çalıştırmak ise tüm alt dizini önceden senkronize etme maliyetini çok yükseltebilir.
  • “Biz sadece yeniden blog olmaya karar verdik. Bu yüzden bunu öğrenmek zorunda kaldık, şimdi siz de öğrenmek zorundasınız” yaklaşımı tam da doğru yol.

• Safça gelebilir ama bunun neden bir güvenlik sorunu olduğunu pek anlamıyorum. Bir makineye ssh ile bağlanabiliyor ve soket port yönlendirmesi yapabiliyorsanız zaten diğer her şeyi yapma yetkiniz var demektir; VSCode protokolü de bunu kendilerine uygun bir şekilde açığa çıkarıyor gibi görünüyor.
  Bunun güvenlik sorunu olmasının nedeni, uzak makineyle aynı ağda olan ama SSH yetkisi bulunmayan birinin SSH ile yönlendirilmiş porta bağlanabilmesi mi, merak ediyorum. Kullanıcı açısından VSCode’un SSH sistemi oldukça iyi çalışıyor ve hoşuma gidiyor.

  • Fark, VSCode’un yaptığı şeyin ssh komutuyla ya da PuTTY ile elde ettiğiniz bir SSH oturumu olmamasında.
    VSCode hedef makineye bir uzak ajan kuruyor, ssh’yi aktarım protokolü olarak kullanıyor ve bu aktarım yolunu kullanıcıyla paylaşacağını söylüyor. Yalnızca istenen işi yaparsa sorun yok; ancak keyfi API’ler açığa çıkaran ajan tabanlı bir sistem, ssh üzerinde terminal taklidi yapan tanıdık ama hâlâ zorlayıcı yöntemden çok daha büyük bir saldırı yüzeyi ve risk yaratır.
  • Asıl nokta, ajanın port yönlendirilmiş SSH üzerinde çalışması ve çalışan VSCode ön yüzüyle bir WebSocket bağlantısı kurması.
    Bu bağlantı üzerindeki protokol dosya sisteminde gezinebilir, keyfi dosyaları düzenleyebilir, kendi shell PTY süreçlerini başlatabilir ve kendini kalıcı hâle getirebilir. İstemciyle uzak sunucuya ssh bağlanmış olmanız, o sunucunun istemcide keyfi kod çalıştırabileceği anlamına gelmez; en azından istemcinin açıkça bir eylem yapması gerekir.
  • Temelde doğru. Bu, özünde bir zafiyet ya da güvenlik sınırını aşma meselesi değil.
    Ancak “curl | bash”in güvenlik sorunu olmasıyla aynı anlamda bir güvenlik sorunu. Daha yakın benzetme, bashrc içindeki curl | bash olabilir.
  • Geliştirme sunucusundaki ajan artık dizüstündeki VS Code’a geri dönen bir ters yönlü vektör hâline geliyor.
    Ajan ağa bağlı ve sürekli çalıştığı için, geliştirme sunucusunun güvenlik duvarındaki bir delik, dizüstünün güvenlik duvarındaki bir deliğe dönüşüyor.
  • Elbette yetki zaten var. Sorun, artık üçüncü taraf bir ajanın bu yetkiyi kendi istediği gibi kullanabilmesi ve kullanıcının bunu fark etmeyebilmesi.

• VSCode’un nasıl çalıştığını öğrendikçe, koli bandı ve JavaScript geliştiricilerinin aklına gelebilecek en lanetli fikirlerle zar zor bir arada tutuluyormuş gibi görünüyor.
  Sadece SSH eklentisine bakınca bile çalışma alanı URI biçiminin iki çeşidi var. Biri fiilen yalnızca ana makine adından oluşan biçim, diğeri ise onaltılık olarak kodlanmış JSON belge biçimi; ikincisi, belirli bir kullanıcı adı gibi ek bilgi gerektiğinde ya da ana makine adında büyük harf olduğunda kullanılıyor.
  Bunun gerçekten gerekli olmasının nedeni, son çalışma alanlarına kaydedilirken bir nedenden dolayı küçük harfe çevrilmesi.
  SSH bağlantısı, sunucuya kurulacak eklenti ayarlarını da destekliyor; ama çok fazla koyarsanız Windows ana makinesine bağlanamıyor. Komut satırı argümanı olarak CMD üzerinden geçiriliyor, CMD’nin 8191 karakter sınırı var ve o CMD ile PowerShell çağrılıyor.

  • VS Code, Eclipse’ten daha iyiydi. IDE üzerinden SSH’ye hiç ihtiyacım olmadı, o kısmını bilmiyorum; genelde PuTTY ile SSH bağlanır, sunucuda çalışmam gerekirse Vi kullanırdım.
  • JavaScript/TypeScript biliyorsanız düzenleyiciye özel dil desteği ya da araç eklemek gerçekten kolay, bu güzel.
    Özel otomatik tamamlama, tanılar vb. sağlayabilir; diller arası destek için özel Go to definition da oluşturabilirsiniz.
  • Koli bandı benzetmesini akla getiren en talihsiz birkaç satır var: https://github.com/microsoft/vscode/blob/6dbde2a3ed308f88164...
    Keşke Microsoft beni birkaç aylığına işe alıp bir köşeye oturtsa ve bu karmaşayı çözmeme izin verse.
  • Çöp ve iplikle birbirine bağlanmış bir şey gibi geldiği için tekrar vim’e döndüm.

• Ağ, ikili exploit ve giriş seviyesi sistem programlama derslerinin sunucusunu işletiyordum; bu şey büyük bir baş belası. Bu aptal uzaktan erişim Truva atı yüzünden öğrenciler OpenSSH istemcisini kullanmayı anlamıyor
  Düzeltmek için birkaç şey denedim. Ders sunucusunun motd’sine VSCode uzak sunucu eklentisini kullanmamalarını yazdım; dersin önünde ncdu /home çalıştırıp sunucuda disk kullanımı 100 MB’ı geçen öğrencilerin istisnasız VSCode kullanıcısı olduğunu gösterdim
  Ayrıca kullanıcı süreç sınırını 45’e çektim; çünkü VSCode uzaktan erişim Truva atı nasıl oluyorsa yaklaşık 50 Node süreci kullanıyor. Öğrenciler motd’yi ve dersteki uyarıları görmezden gelirse sınıra takılıyor, tekrar bağlanmak için bizden süreçleri öldürmemizi istemek zorunda kalıyordu
  Sonunda süreç sınırı yerine, her 10 saniyede bir tüm .vscode-server uzaktan erişim Truva atlarını öldüren bir betiğe geçtim

  • Üniversite yıllarımda, okulun sistem yöneticilerinin ağa koyduğu anakronik derecede katı kısıtlamaları aşmaya çalıştığım anıları çokça hatırlatıyor
  • Bu sadece VSCode popüler olduğu için olan bir şey değil. 10 yıldan da önce üniversitedeyken bile Sublime’a SFTP eklentisi takıp kullanan ya da yerelde kodlayıp dosyaları FileZilla gibi GUI istemcileriyle taşıyan öğrenciler vardı
    Asistanlık yaptığım bir derste, temel makine kodunu işleyip öğrendiğimiz ISA’nın assembly ve çalıştırma araçlarını taklit eden bir ödev vardı; öğrencilerin hexdump gibi şeylerle dosyanın bayt yapısını anlaması gerekiyordu
    Ama Sublime, nesne dosyasını “yardımsever” biçimde hexdump’ın metin gösterimi gibi render edip okunabilirlik için boşluklar ekliyor, okulun Linux sunucusunda hexdump yapıldığında görünenden farklı bir endianness sırası gösteriyordu
    Her dönem birkaç öğrenci, AD DE EF BE gibi bir ASCII dizgesini okumak için yazdığı kodun neden tanımadığı bir metin aradığını sormaya gelirdi; aslında bayt değerlerinin 0xDE, 0xAD, 0xBE, 0xEF ile başladığını kontrol etmemiş olurlardı
  • Neden bu kadar ileri gitmek gerektiğini merak ediyorum. VSCode’u engellemek için çok emek harcandığını anlıyorum ama VSCode’un somut olarak neye yol açtığı net değil
  • 50 Node süreci mi; her gün Tanrı’dan biraz daha uzaklaşıyoruz
  • Buradaki “murid”in neyi kastettiğini merak ettiyseniz ve RAT’i de ilk kez duyuyorsanız, RAT Remote Access Trojan kısaltmasıdır

• Burada alternatifin ne olduğundan pek emin değilim. VSCode’un SSH ile düzenleme özelliği şaşırtıcı derecede iyi çalışıyor; uzak makinede vim, nano, micro kurcalamayı çoktan bıraktım
  Ajan, araya girmeden sessizce çalışmamı sağlıyor. Neredeyse yerel makinede çalışıyormuşum gibi; benim için büyük bir artı
  Güvenlik riski olabilir ama geliştirme deneyimi kıyas kabul etmiyor. VSCode’un hangi başka editörü öldürdüğüyle pek ilgilenmiyorum; araç işime engel olmadan çalışmamı sağlasın yeter

  • Alternatif, TRAMP’ın önerdiği yaklaşıma daha yakın. Bildiğim kadarıyla TRAMP, uzağı bir yürütme host’u olarak değil, ağ dosya sistemi gibi ele alıyor
    İkili dosya dağıtmıyor; baytları pipe üzerinden okuyup yazıyor ve anlamlı yürütmenin tamamı yerelde gerçekleşiyor. Özellikle kalıcılık oluşturmuyor; “SSH ile bağlı olduğun sürece VSCode eklentisi erişebilir” ile “VSCode eklentisi sonsuza dek erişebilir” aynı şey değil
  • Güvenlik riski, doğrulanmamış eklentilerin editöre sınırsız erişime sahip olmasından geliyor
  • Gördüğüm kadarıyla VSCode kullanan iş arkadaşları, farkında olmadıkları şekillerde kısıtlanıyor; daha iyi bir yöntemin ne kadar iyi olabileceğine dair fikirleri yok
    Birden çok uzak ortamda çalışırken nerede bağlı olduklarını, bağlantı durumunun ne olduğunu çoğu zaman bilmiyorlar. Terminal yavaş, oturum durumu kalıcılığı ise dengesiz
    tmux ve düzgün bir metin editörü kullanmaktan çok daha kötü bir deneyim. Üstelik sunucu çok ağır ve düzgün kapanmıyor; altı tane sunucu örneği açık bırakmak da yaygın
    Güncellemelerin yarısı bozuluyor; gerçek ssh istemcisiyle host’a girip bozuk vscode sunucusunu nasıl temizleyeceğini bilmediği için bir saat kaybedenler oluyor
  • VSCode’un tam olarak hangi işlevleri sunduğunu bilmiyorum ama birden çok uzaktan düzenleme işi için sshfs oldukça iyi uyuyor. Temelde VSCode’a benzer olması gerekiyor gibi
  • Emacs’in TRAMP’ı da epey kötü, ama yine de VSCode uzaktan düzenleme karmaşasından daha kararlı ve kullanıcı dostu

• Ne öğrenmiş olduk? Uzaktan kod çalıştırmanın var olduğunu mu? Geliştirme araçlarına yanlış yerde duyulan güvenin çoğu zaman pişmanlık getirdiğini mi? Modern yazılım tasarımının berbat olduğunu mu? Biraz dikkat edilseydi bunların hepsi zaten apaçıktı
  SSH, 90'ların çözümü. Birkaç özellik eklenmiş Telnet; “secure” shell diye anılıyor ama kelimenin tam anlamıyla Telnet+TLS'ten daha az güvenli
  Sunucuda kullanıcı oturumu olan bir tünele zaten sahip oldukları için, uygulamaya özel ağ aktarımı ve güvenli bağlantı protokolü yapmaya gerek olmadığına karar veren insanlar SSH'nin üstüne türlü tuhaf ama övülen şeyler bindirdiler
  Dağıtık işletim sistemlerinden öğrenilen kavramları bir kenara atıp, o zamana kadar geliştirilmiş ileri kimlik doğrulama ve yetkilendirmeyi yok sayıp, en kötü ve en kolay şeyi benimsemenin sonucu bu
  Böyle bir “SSH agent”ın saçma olması şaşırtıcı değil. İşe uygun doğru araçları yapmak için harekete geçmedik; bu yüzden de o amaç için tasarlanmamış mevcut araçların içine sürekli daha fazlasını tıktık. Şaşırmış gibi davranmaya hakkımız yok
  Bu bizim yarattığımız dünya. Emekle ya da sessiz onayla hepimizin yarattığı bir şey. SSH olmasa da siyaset, ticaret, okul ve diğer her şeyde de durum aynı. Her gün kendi yığdığımız yığının içinde yaşıyoruz; bir şey yapmadığımız her gün de üstüne bir kürek daha atmış oluyoruz. Küreği elimizde tutarken bunun şaşırtıcı ya da çılgınca olduğunu iddia edemeyiz

  • Bunu geliştiriciler değil, ağ güvenliği sorumluları yarattı. HTTPS ve ssh dışındaki tüm giden portları kapatırsanız, sonrasında her şey mecburen HTTPS ya da ssh üzerinden tünellenir
    Bu yüzden genel olarak giden HTTPS bağlantılarına izin veriyorsanız, SMTP hariç tüm giden bağlantılara da izin vermek daha doğru olur. Gerçek kötü amaçlı trafik zaten her hâlükârda HTTPS üzerinden tünellenecek; geriye kalan tek etki, tünelin karmaşıklığını ve verimsizliğini taşımayan yeni protokollerin dağıtımını engellemek olur
  • Öte yandan SSH anahtar çiftiyle kimlik doğrulama ve sertifikalar, bildiğim kimlik doğrulama yöntemleri içinde en iyileri bence. Ön ayar gerektirmeden FIDO2 ile de entegre oluyor
    Web girişlerinin de SSH'nin yaptığı yönteme daha yakın olmasını isterdim
  • Bu güçlü bir komplo teorisi havası veriyor. Dünyadaki her şey kötü niyetle dönmüyor; çoğu zaman insanlar baskı altında akıllarına gelen en iyi şeyi deniyor
    Arada dışarı çıkıp çimlere dokunmak ruha iyi gelir. Ayrıca daha iyi bir SSH protokolünün nasıl yapılabileceğine dair öneri de duymak isterim. Yapıcı eleştiri içermeyen şikâyetin pek faydası yok

• Buradaki “SSH agent” terimi kafa karıştırıcı. Çünkü normalde kimlik doğrulama token'larını önbelleğe alan daemon'u ifade eder

  • Doğru. VSCode bir SSH Agent sağlamıyor, yerel SSH Agent ile iletişim kuruyor. Aslında kendi ForwardAgent sürümü gibi; bunun güvenlik sonuçları da aynen geçerli
    Üstelik bu yöntem, meşhur macOS SSH agent'ını bozuyor: https://github.com/maxgoedjen/secretive/issues/543
  • “SSH Agent”ın başında “VSCode” olduğu için ayrım aslında oldukça iyi yapılıyor

• Üretim sunucularında vscode remote kullanmanın çılgınlık olduğuna tamamen katılıyorum
  Ama “saçma” diye tarif edilen diğer özellikler beklenebilecek özellikler gibi geliyor

  • Güvenlik sonuçlarını düşününce bu özelliğin kullanım senaryosunun ne olduğunu merak ediyorum. Diğer ortamlardan yeterince yalıtılmış bir staging instance olabilir belki

• MAANG'de staff engineer seviyesine kadar geldim ve bunun sıradan Vim ile elde etmesi zor bir seviye olduğunu düşünüyorum. Yine de diğer yüksek performanslı kişilerin hâlâ Vim ya da Emacs kullanma eğiliminde olduğunu görüyorum
  VCode, JetBrains vb. kullanan çok iyi geliştiriciler de çok, ama giriş engellerini arayıp bulma, araçların büyüsünü keşifle sökme ve tamamen açık kaynak, son derece kurcalanabilir, topluluk odaklı projelere değer verme eğiliminin bu durumu özelliklerden ya da kullanım kolaylığından daha iyi açıkladığını düşünüyorum
  VSCode'un uzaktan düzenlemesinin ne kadar karmaşık olduğunu okuyunca VSCode'u daha az kullanmak istiyorum. Makineye ssh ile girip o makinedeki editörü kullanmak yeterli
  VSCode'un çözümü çalışıyor ama ne zarif ne de evrensel olarak uygulanabilir; ayrıca bozulmaya daha yatkın. Emacs kullanıcılarından özür dilerim ama Tramp hâlâ epey berbat, netrw de daha iyi değil

  • Tramp'ın harika olmadığına katılıyorum, ama daha iyi çalışan basit bir çözüm var: watchexec + rsync
    Belirli dosya yollarını izleyip yalnızca gerekenleri tam olarak senkronize edebiliyorsunuz. Hâlâ yerel dosya sisteminde çalıştığınız için düzenleme gecikmesi yok, tüm yerel araçları kullanabiliyorsunuz ve senkronizasyon milisaniyeler içinde bitiyor
    Yerelde sildiğiniz dosyaların uzakta da silinmesini sağlayabiliyorsunuz ve uzak makinedeki iş bittikten sonra da her zaman yerel bir kopyanız kalıyor. Tramp'ta bunu hep elle senkronize etmek gerekiyordu. Üstelik editörden bağımsız
    VS Code'un bu özelliği, artık gerçekte ne yaptığını bildiğim için beni huzursuz ediyor
  • VSCode merkezli yeni bir ekibe katıldıktan sonra da neden hâlâ vim'i tercih ettiğimi çok düşündüm. Son gözlemim, araç çubuğu ve ekranı dolduran diğer öğelerin görsel olarak fazla gürültülü olduğu
    Copilot'ı açınca araç çubukları daha da arttı ve kullanmaya çalıştığım yere metinler fırladı. Vim sadece koda bakmama, düşünmeme ve yazmama izin veriyor. VSCode ile akış hâline girmek zor
    30'larımın ortasındayım; üniversitede emacs kullanmıştım, ilk işimde vim'e geçtim. Çok çetrefilli Java projelerinde IntelliJ kullandım ama onun dışında hep vim kullandım
  • Hobi olarak kod yazarken araçları keşfetmeyi ve büyüyü sökmeyi severdim. Şimdi işim olunca VSCode'u seviyorum. Çok kurcalamak gerekmiyor, işi bitirmeye odaklanabiliyorum
    Karmaşık regex işlemleri gerektiğinde ara sıra vim'i açıyorum
  • Ekibimizdeki principal engineer ve distinguished engineer Vim ve Emacs kullanıyordu

• VSCode, mevcut uzak araçlarla birlikte çalışmak yerine Node.js ikili dosyası kurulumu, VSCode ön yüzüne dönen WebSocket bağlantısı ve geniş kapsamlı sistem erişimi işlevleri içeren kapsamlı bir ajan dağıtıyor.
  Bu VSCode ajanı, dosya sisteminde gezinme, dosya düzenleme, shell PTY süreçleri oluşturma ve kendini kalıcı kılma yeteneğine kadar geniş yetkilere sahip.

  • VSCode’un yerelde kurulu olmayan uzantıları çalıştırmak gibi yaptığı işleri destekleyecek makul bir alternatif pek görünmüyor. Böyle bir işlevi istemeyebilirsiniz, ancak bu ürünün özellik setinin bir parçası.
  • Bu sorunun yerel VS Code örneğinin mi yoksa uzak örneğin mi sorunu olduğu net değil.
    Uzak taraftaysa, elisp Tramp’ın bağımlılıklar açısından daha hafif olduğunu anlıyorum; ancak saldırı yüzeyinin gerçekten bu kadar farklı olup olmadığını merak ediyorum. Yani uzak Node ikili dosyasının, keyfi ssh komutları çalıştıran kullanıcının sahip olmadığı yetkilere sahip olup olmadığını bilmiyorum.
    Asıl hedef LLM’ye geçici ve gözden çıkarılabilir bir sanal makinenin tüm anahtarlarını vermek idiyse, ajanın açtığı soket yüzünden yalıtmak istediğiniz geliştirici makinesine de erişebileceği mi söyleniyor, bunu merak ediyorum.
  • Bir açıdan bakıldığında, bunların modern işletim sistemlerinin standart özellik olarak sunması gereken şeyler olduğu ve VSCode’un böyle özellikler olmadığı için etrafından dolandığı söylenebilir.
    Çılgınca bir fikir gibi gelebilir ama çekirdeğin kendisi şifreleme ve kimlik doğrulama içeren bir web sunucusu ya da başka bir protokol sağlayabilir ve eBPF üzerinden tüm makinenin doğrudan kontrol edilmesine izin verebilir. Bu, istemci/sunucu uzaktan kontrolü için tamamen farklı bir paradigma olabilir.
    Elbette Death Star’ın içinden geçebileceği kadar büyük bir güvenlik açığı da olabilir.