KeePassXC Debian yöneticisi tüm ağ özelliklerini kaldırıyor

 (fosstodon.org/@keepassxc)
1 puan yazan GN⁺ 2024-05-12 | 1 yorum | WhatsApp'ta paylaş
  • Debian’daki keepassxc paketi asgari işlev paketine dönüştüğünde, mevcut özellikleri korumak isteyen kullanıcıların keepassxc-full paketine geçmesi gerekecek
  • Kaldırma kapsamı ağ özellikleriyle sınırlı değil; YubiKey, auto-type, tarayıcı entegrasyonu, SSH agent, FDO secrets, favicon indirme ve HIBP de dahil
  • Debian paket açıklaması, varsayılan keepassxc paketinin yalnızca “bare minimal functionality” sunduğunu belirtiyor; ağ özellikleri, SSH agent, tarayıcı eklentisi ve FDO secret storage’ı güvenlik açısından karmaşıklık olarak sınıflandırıyor
  • Değişiklik duyurusu NEWS.Debian.gz ve apt-listchanges üzerinden iletilecek; stable kullanıcılarının sürüm notlarını kontrol etmesi gerekiyor
  • Paket adı ve geçiş yöntemi hâlâ ayarlanabilir durumda; Trixie sonrasında apt install keepassxc komutunun iki seçeneği göstermesi de gündeme geliyor

Debian keepassxc paketindeki değişiklik

  • Team KeePassXC, Debian kullanıcılarına keepassxc paket yöneticisinin özellikleri büyük ölçüde kaldırmayı planladığını bildirdi
  • Değişiklik testing/sid dışına yansırsa, mevcut özelliklere ihtiyaç duyan kullanıcıların keepassxc-full paketine geçmesi gerekecek
  • Debian hata raporu ağ desteğinin devre dışı bırakılması gibi görünse de Team KeePassXC, gerçek değişikliğin ağ özelliklerinin ötesinde, neredeyse tüm özelliklerin kaldırılması olduğunu savunuyor

Kaldırılacak özelliklerin kapsamı

  • Team KeePassXC’nin açıkladığı kaldırılacak öğeler şunlar
    • YubiKey
    • auto-type
    • tarayıcı entegrasyonu
    • SSH agent
    • FDO secrets
    • ağ özellikleri
    • favicon indirme
    • HIBP

Debian paket açıklaması ve gerekçesi

  • Debian sid’deki keepassxc paket açıklaması, varsayılan paketin yalnızca asgari işlevleri içerdiğini belirtiyor
  • Bu açıklama; ağ özellikleri, SSH agent, tarayıcı eklentisi ve FDO secret storage’ı güvenlik açısından karmaşıklık olarak görüyor ve gerçekten gerekiyorsa keepassxc-full kullanılmasını öneriyor
  • İlgili Debian hata raporu olarak #953529 - keepassxc: Compiling with disable networking support paylaşıldı

Debian yöneticisinin tutumu

  • Debian yöneticisi, beklenmedik değişiklikleri kontrol etmek için ilk yer olarak /usr/share/doc/<package>/NEWS.Debian.gz dosyasını gösteriyor
  • testing/unstable kullanıcıları apt-listchanges kuruluysa değişiklikleri otomatik olarak görebilir; stable kullanıcılarının ise sürüm notlarını okuması gerekiyor
  • Bu kararın 1 yıl boyunca tartışıldığını ve xz-utils olayı sonrasında varsayılan olarak dahil edilen kodu mümkün olduğunca azaltma yönüne eğilim oluştuğunu belirtti
  • Yönetici; Debian, KeePassXC ve çok özellikli bir parola yöneticisi isteyen kullanıcı kitlelerinin büyük ölçüde örtüştüğünü düşünmüyor
  • Yerel kullanıma yönelik bir parola yöneticisine “delik” açmanın mantıklı olmadığını ifade ediyor

upstream ve downstream arasındaki iletişim sorunu

  • Bir kullanıcı, tartışma uzun sürmüş olmasına rağmen upstream geliştiricilerin tamamen şaşırmış gibi görünmesini sorun olarak dile getirdi
  • Debian yöneticisi bunun Debian projesinin iç meselesi olduğunu ve IRC’de diğer Debian geliştiricilerinden görüş aldığını söyledi
  • upstream’in tutumunu zaten bildiğini, upstream’in IRC’den yıllar önce ayrıldığını ve yeni sürüm paketleme işinin bile enerjisini tükettiğini açıkladı
  • Team KeePassXC ve bazı kullanıcılar, downstream kararı nedeniyle upstream’e hata raporları ve kafa karışıklığı yığılabileceğinden endişe ediyor

Paket adı ve geçiş yönü

  • Birçok kullanıcı, varsayılan keepassxc paketini asgari işlev paketine çevirmek yerine keepassxc-minimal veya keepassxc-light gibi bir ad kullanılmasının ve mevcut keepassxc paketinin tam özellikleri korumasının daha az kafa karıştırıcı olacağını önerdi
  • Bir öneride yapı şu şekildeydi
    • keepassxc-light
    • keepassxc-full
    • keepassxc, keepassxc-full paketine bağımlı bir geçiş paketi
    • değişikliği açıklamak için NEWS.Debian
  • Debian yöneticisi, ad değişikliğinin ftpteam onayına bağlı olduğunu ve Trixie geçiş paketi yönü için bu önerinin en iyi seçenek olabileceğini söyledi
  • Trixie sonrasında geçiş paketinin kaldırılması ve apt install keepassxc komutunun iki seçeneği göstermesi de gündeme geldi

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-12
Hacker News yorumları

  • Upstream’in yazılıma koyduğu özellikleri büyük ölçüde kaldırıp aynı adla dağıtmak en iyi ihtimalle şüpheli görünüyor.
    Bu yönde ilerlemek istiyorlarsa farklı ad taşıyan bir fork olarak dağıtmalılar; böylece upstream de kullanıcıların sorun bildirimleriyle sürekli uğraşmak zorunda kalmaz.
    Eskiden Debian’ın Chromium bakımcısının eklenti kurma özelliğini tek taraflı devre dışı bırakıp sonunda yamanın geri alındığı olayı hatırlatıyor.
    Çok daha önce de Debian’ın ağ kartlarına binary firmware yükleyen kernel arayüzünü kaldırıp ağımı bozduğu olay aklıma geliyor.

    • Aslında yaptıkları tek şey XC_ALL derleme parametresini OFF yapmak [0]; bu değer upstream CMakeLists.txt dosyasının da varsayılanı 1.
      Upstream bu özelliği bu kadar önemli görüyorsa önce varsayılan değeri düzeltmeli.
      Yükseltmeden sonra özellik durduğu için kullanıcıların kafası karışabilir; ancak son eki olmayan paketin upstream varsayılanıyla uyumlu olması kendi başına oldukça makul.

      [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
      1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...

    • Bakımcının rolü upstream’i kopyalayıp yapıştırmaktan ibaret değil.
      Dağıtımın son kullanıcıları için neyin uygun olduğuna karar verme yetkisi var.
      Bu durumda makul bir güvenlik gerekçesi var gibi görünüyor ve alternatif paket de sunuluyor.

    • Debian, upstream’i görmezden gelen tuhaf bir tavra sahip tek dağıtım gibi.
      Benim bakımını yaptığım iki upstream projede de Debian tek taraflı olarak paket adını değiştirdi.
      Birini çok sonra öğrendim; diğerinde ise açıkça karşı çıkmama rağmen tamamen anlamsız bir şekilde ilerlediler.
      Sonunda kullanıcılara açıklama yapmak zorunda kalan benim.

      Düzeltme: Debian tarafındaki Julian’ın kibri burada görülebilir: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — kastettiğim şey tam da bu.

    • Upstream’in yaptığı şeyi “kesip biçmiş” değiller.
      Eklentisiz sürümü dağıtıp, eklentilerin dahil olduğu -full sürümünü oluşturmuşlar.
      Eklenti varsayılan olarak takılı geliyorsa o artık eklenti değil, yerleşik özelliktir; bu yöntem doğru.

    • Apple “güvenlik açısından daha iyi olduğunu düşündüğümüz için uygulamanızı değiştirdik” deseydi insanlar meşaleler ve dirgenlerle ortaya dökülürdü.
      Ama bunu bir deb bakımcısı yapınca tartışma konusu oluyor.
      Güvenlik sorunu varsa güvensiz sürüm hiç sunulmamalı; ancak bu durumda o da söz konusu değil.
      App Store benzeri bir dünyada bakımcının rolü değişmeli.
      Yapılması gereken, yazılımın dağıtımda çalışmasını sağlamak; adı koruyup kendi zevkine göre yarı-fork üretmek değil.

  • Oldukça makul bir karar gibi görünüyor.
    Ağ özellikleri ve tarayıcı entegrasyonu büyük potansiyel açıklar ve saldırı giriş noktalarıdır.
    Ağla ilgili özellikler olmadan yalnızca güvendiğiniz veritabanını çalıştırırsanız, bir zafiyet bulunsa bile aracı kötüye kullanmak neredeyse imkânsız olmalı; parola yöneticisi gibi kritik bir araç için bu çok arzu edilir bir özellik.
    Asıl bakımcı da buna katılıyor 1.
    Ağın açık olduğu tam paket de Debian’da mevcut; isteyen kullanıcılar tüm ağ özelliklerini kullanmak için sadece apt install keepassxc-full çalıştırabilir.
    Ancak upstream’e “crappy”[0] demek bir paket bakımcısı için yapıcı bir tutum değil; paket adları da keepassxc ve keepassxc-full yerine keepassxc-lite ve keepassxc-full olsaydı Debian kullanıcıları için daha anlaşılır olurdu.

    [0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    • Pek çok şey büyük potansiyel açık ve saldırı giriş noktasıdır; aynı zamanda faydalıdır da.
      “Faydalılık” güvenliği artırabilir.
      Çünkü bir parola yöneticisini kullanmak zorsa insanlar kullanmayı bırakır.
      Biraz daha bakınca panonun kullanımının tarayıcı entegrasyonundan mutlaka daha güvenli olup olmadığı da belirsiz.
      Yalnızca kopyala/yapıştır hataları bile tarayıcı entegrasyonunun güvenlik yükünün önemli bir bölümünü dengeleyebilir.
      Uzun zaman önce büyük bir şirkette sözleşmeli iş yapmıştım; hesap yöneticilerinin dizüstü bilgisayarlarında disk şifreleme parolası, Windows oturum açma parolası ve AD oturum açma parolası vardı; hepsi farklı olmak zorundaydı, birkaç ayda bir değiştirilmeleri gerekiyordu ve karmaşıklık şartları da çok ağırdı.
      Gördüğüm tüm dizüstü bilgisayarlarda, istisnasız, üç parolanın da yazılı olduğu post-itler yapıştırılmıştı.
      Ana fikir şu: varsayımsal güvenlik meraklısı güvenliği gerçek dünyadaki güvenlikle aynı şey değildir.
      En azından her zaman aynı değildir ve burada gerçek bir ödünleşim gerekir.

1: Dış yüklenici olarak bazı çalışanların dizüstü bilgisayarlarının bakımını yapıyorduk
Aslında böyle olmaması gerekirdi ama şirketin BT sisteminden geçince bürokrasi yüzünden çok uzun sürdüğü için bu çok daha hızlı ve kolaydı
Öyle bir şirketti
Bu da elbette başlı başına bir “güvenlik riski”ydi; çünkü bir bilgisayar mağazasındaki rastgele bir teknisyenin, içinde çok gizli şirket verileri olan dizüstü bilgisayarlara dokunması zaten doğru değildi
Yine de korunacak şeyin o kadar fazla olmadığını düşünüyorum. Satış/müşteri rakamları kadardı ve yalnızca çok sınırlı sayıda kişi için işe yarayabilecek bilgilerdi

  • Tarayıcı entegrasyonunun elle kopyala/yapıştırmaya göre güvenliği artırdığı bir yön var
    Tarayıcı eklentisi, kimlik bilgilerini doldurmadan önce sayfa URL’sini kontrol eder; elle kopyala/yapıştır ise yazım hatalı alan adlarına veya homoglif kimlik avına karşı savunmasızdır

  • Ağ özelliklerinin ve tarayıcı entegrasyonunun büyük potansiyel açıklar olduğu konusunda katılıyorum; ancak GitHub issue’sundaki katılımcıların söylediği gibi, tam derlemeye kıyasla küçültülmüş derleme testlerinin neredeyse hiç olmaması ve rastgele derleme bayrağı kombinasyonlarının hiç test edilmemesi önemli
    Başka yerlerde de belirtildiği gibi, devre dışı bırakılan “seçenek” bayraklarından biri yubikey desteği ve bu yüzden yeni bozulmuş pakete yükselten kullanıcılar parola yöneticilerinin dışında kalıyor
    Sadece o bayrağı yeniden açmak bile pratikte kimsenin test etmediği bir duruma yol açıyor
    Mevcut kullanıcıların keepassxc-full paketine geçirildiği varsayımıyla, adın keepassxc-lite olmasının sorunu önleyeceğine katılıyorum
    Ama asıl mesele de tam olarak bu
    En güvenli çözümü varsayılan yapmak makul; ancak bakımcı, upstream ya da kullanıcılar istemediği sürece mevcut işlevleri bozmamalı ve özellikle kullanıcıları parola yöneticilerinin dışında bırakmamalı

  • GitHub’a “crappy” yazması o kadar kaba ki, Debian kullanıyor olsaydım kullanmayı yeniden düşünürdüm
    Paket bu kadar berbat özelliklerle doluysa neden bakımını üstlendiğini bilmiyorum
    En iyisi tamamen kaldırıp kullanıcıların düzgün kurulum yolunu kendilerinin bulmasına bırakmak olurdu
    KeepassXC geliştiricilerine üzülüyorum; açık kaynak proje sürdürmek zaten zor, bir de böyle şeylerle uğraşmak zorunda kalıyorlar

  • crappy ifadesini gördüğüm anda julian-klode’a duyduğum saygı doğrudan yok oldu

  • drawks’ın önerdiği çözüm açıkça doğru tercih gibi görünüyor:

    Uygun çözüm muhtemelen yazılımın hem "-full" hem de "-minimal" sürümlerini paketlemek, Debian paket meta verisi alanlarıyla iki paket arasında Conflicts ilişkisi tanımlamak, ikisini de keepassxc Provides edecek şekilde etiketlemek ve -full derlemesine ayrıca Replaces: keepassxc etiketi eklemek olurdu. Böylece paket yükseltmesi sırasında mevcut kullanıcılar, yükseltilen/değiştirilen paketin işlevlerini sağlamaya devam eden sürümü alır; yeni kullanıcılar ise hangi sürümü kuracaklarını kendileri seçebilir

    https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    Bunun neden bariz seçenek olmayabileceğini bilmiyorum

    • Çünkü bakımcının kendi görüşü vardı ve açıkça varsayılanı değiştirmek istiyordu

    • Bu yalnızca bariz seçenek olmakla kalmadı, gerçek Debian’da tam olarak böyle oldu: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

      Orijinal yazı sadece kötü yazılmış bir tık tuzağı
      Hiçbir şey kaldırılmadı, yalnızca keepassxc-full paketine taşındı

  • Öte yandan Arch tarafında, muhtemelen kullanıcı tabanında epey yaygın kurulu olan fwupd paketi sessizce passim’e bağımlı olacak şekilde ayarlandı; passim ise açık kullanıcı rızası olmadan 0.0.0.0:275001 üzerinde açık bir web sunucusu başlatıyor
    Üstelik passim, deliklerinin İsviçre peynirinden fazla olmasıyla bilinen GnuTLS’i kullanıyor 2
    Bunun gerçekten akıl almaz olduğunu düşünüyorum ve zincirin bir yerinde xz türü bir exploit gizli olsa şaşırmam

    • fwupd’yi aramaya bile gerek yok
      Her yerde bulunan systemd-resolved, istek üzerine 5355 portunda bir LLMNR sunucusu, yani mDNS diye de anılan ve eski Microsoft NetBIOS ailesinden gelen şeyi açabiliyor
      Nesnelerin interneti yüzünden herkesin LAN’ıma erişebildiği bir çağda, artık Linux’u da o curcunaya dahil ettiriyoruz

      fwupd düzeltmesi için varsayılan yapılandırma dosyasının kalitesi düşük ve yorum satırına alınmış varsayılanlar bile yok; bu yüzden şöyle yapmak yeterli:

      # /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none

      resolved düzeltmesi /etc/systemd/resolved.conf içinde LLMNR=no olarak yorum satırına alınmış durumda; muhtemelen DNSStubListener=no da isteyeceksiniz
      Düzgün varsayılanlar şöyle:

      # /etc/systemd/resolved.conf  
[Resolve]  
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net  
FallbackDNS=127.0.0.1 ::1  
Domains=~.  
DNSOverTLS=yes  
LLMNR=no  
DNSStubListener=no

    • Bunu bilmek iyi oldu
      Bence bu ayrı bir yazı olarak da paylaşılabilir

  • Paket yöneticisinin en az şaşırtma ilkesine göre hareket etmesi ve belgelenmiş ya da en azından makul bir risk olmadığı sürece temel işlevleri devre dışı bırakmaması gerektiğini düşünüyorum.
    Bu yorum bölümünde “eklenti” kelimesi şu anda 25 kez geçiyor, ama burada söz konusu olan şey eklenti değil.
    KeePassXC’de çok sayıda özellik var, ancak açık bir kullanıcı eylemi olmadan kendi başına olası bir zafiyet kaynağı olacak bir şey görünmüyor.
    Tarayıcı entegrasyonunun önce etkinleştirilip sonra yapılandırılması gerekiyor; bu bayrakla devre dışı bırakılan diğer özellikler de muhtemelen aynı, dolayısıyla -minimal paketi daha uygun olurdu.
    Belirsiz bir gelecekte bu değişiklikten fayda görecek çok az sayıdaki kullanıcıya kıyasla, tarayıcı entegrasyonunu kullananların yaşayacağı ciddi rahatsızlık çok daha büyük.
    Tarayıcı entegrasyonu ayrıca genel olarak panoya erişimden çok daha güvenli bir özellik.
    Projenin vizyonuyla da uyumlu görünmüyor:

    Amaç, herkesin kullanabileceği ve ihtiyaç duyanlara gelişmiş özellikler de sunan bir uygulama oluşturmak.

  • Mevcut kullanıcıları bozmadan da bu ayrım yapılabilirdi; bu yüzden bunu Debian paket yöneticisinin kötü kararı dışında başka türlü görmek zor.
    Ağ işlevleri olmayan KeepassXC kullanabilmek elbette iyi, ancak tarayıcı entegrasyonunu niş bir özellik olarak görmek gerçeklikten ciddi biçimde kopuk.
    Şu anda Debian’da KeepassXC kullananların yarısından fazlasının, hatta muhtemelen çok daha fazlasının, bu yöntem yüzünden haber verilmeden devre dışı bırakılacak özellikleri istediğine para yatırırım.
    Sonuçta karar yetkisi onlarda, ama bu onun iyi bir karar olduğu anlamına gelmez; bence değil.

  • KeePassXC yöneticisinin sözleri:

    Bu başlık açılmadan önce, bu yeni paketleme yönteminin insanların iş akışlarını bozduğuna dair üç rapor aldık. Bunlardan biri, yubikey işlevi kaldırıldığı için veritabanını artık açamayan bir kullanıcıydı. Bir an bunu düşünün. En önemli sırlarına erişemeyen biri panik halinde bazen mantıksız davranabilir.

    https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    • Çevrimdışı bir parola yöneticisi kullanıp yedek yoksa, her şeyi kaybetmiş sayılırsınız.
      Bu duygusal şantaj gibi geliyor.
      Donanım arızası, işletim sistemini bozan bir güncelleme, yanlış diske dd kullanmak vb. yüzünden her şeyin kaç kez kaybedildiğini bilmiyorum.

  • Bir downstream yöneticisi, paketi upstream projenin niyetinden farklı bir şekilde değiştirecekse, bunu farklı bir adla dağıtmalı ve o değiştirilmiş sürümden kaynaklanan tüm hata raporlarını kendisi ele almalı diye düşünüyorum.

    • Varsayılan derlemede ağ desteği OFF.
      Yubikey, tarayıcı entegrasyonu vb. için de aynı.

      -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)

      https://github.com/keepassxreboot/keepassxc/blob/develop/INS...

    • WITH_XC_NETWORKING derleme seçeneği varsayılan olarak kapalı olduğuna göre, geliştiricilerin bu yapılandırmayı geçerli bir derleme ayarı olarak amaçladığı açık.

    • Genelde buna pek uyulmadığını biliyorum, ama normal akış aslında böyle olmalı.
      Dağıtımın sağladığı paketi kullanırken bir hatayla karşılaşırsanız, dağıtım paketinde bir hata kaydı açarsınız; yönetici bunu inceler ve upstream’den gelen bir hata ise upstream projeye taşır.
      Bu yöntemin yararlı olmasının nedeni şu: 1. Paket yöneticisi ilgili pakete aşinadır, ilk sınıflandırma ve analizi yapabilir, hatta upstream’e gitmeden hemen düzeltebilir; 2. dediğiniz gibi dağıtım paketleri çoğu zaman yamalar içerir, bu yüzden yöneticinin sorunun paketlemede mi yoksa upstream kaynakta mı olduğunu doğrulaması gerekir.
      Ne yazık ki birçok kullanıcı önce upstream’e rapor ediyor.
      Bu yüzden pratikte endişelenmeye değer, ama aslında böyle olmamalı.

    • Ya da son kullanıcıya bunun desteklenmeyen bir paket olduğu belirtilmeli.
      Örneğin KeePassXC-Debian ya da KeePassXC-Unsupported olarak görünmesi ve About bölümünden geliştirici iletişim bilgileri ya da web sitesinin çıkarılıp Debian destek bilgileriyle değiştirilmesi gibi.
      İşletim sistemine uyum sağlamak için yapılan küçük downstream değişiklikler sorun değil.
      Ama uygulamayı değiştirip temel özellikleri kaldırmak ve upstream geliştiricilerin büyük miktarda şikâyet almasına neden olmak sorun.

    • Bağlantısı verilen 200 karakterlik yazıyı bile okumadan neden yorum yaptığınızı bilmiyorum.
      Yönetici, keepassxc-full paketinde ağ ile ilgili olanlar dahil tüm eklentileri etkinleştirdi; keepassxc paketi ise çok daha iyi bir güvenlik duruşuna sahip temel işlevleri içeriyor.
      Bu açıkça tamamen kabul edilebilir ve yöneticinin yetki alanı içinde.
      Bütün şikâyet bunun bir değişiklik olmasından ibaret.

  • İlgilenenler için GitHub’daki bu issue en güncel yorumları içeriyor gibi görünüyor.

    https://github.com/keepassxreboot/keepassxc/issues/10725

    • Debian yöneticisi Julian Klode’un görüşü oldukça sert:

      Üzgünüm ama öyle olmayacak. Varsayılan olarak tüm eklentileri derleyip dağıtmak bir hataydı. Kullanıcılar okumaları gereken NEWS dosyasını can sıkıcı biçimde okumadıkları için yaklaşık 1 yıl acılı geçecek, ama yapabileceğimiz pek bir şey yok.

      Kullanıcılara varsayılan olarak mümkün olan en güvenli seçeneği sunmak bizim sorumluluğumuz. Bu özelliklerin hepsi gereksiz ve yerel bir parola veritabanı yöneticisine aslında ait değil. Bu geliştirme yönlerinin tamamı tamamen yanlış.

      Bu çöpe ihtiyaç duyan kullanıcılar çöp sürümü kurabilir, ama bu doğal olarak yoldan geçen katkıcı saldırısı riskini artırır.

  • Başlık yanlış.
    Asıl yazı, yöneticinin yalnızca ağ işlevlerini değil tüm işlevleri kaldırdığını söylüyordu; gerçekten de tüm isteğe bağlı işlevler, tamamen çevrimdışı olanlar bile derleme sırasında kapatıldığı için bu doğruydu.