NixOS yeniden üretilebilir derlemeler: minimal kurulum ISO’su bağımsız olarak yeniden oluşturuldu
(discourse.nixos.org)- NixOS’un minimal kurulum ISO’sunun Hydra dağıtımıyla bit düzeyinde tamamen aynı olacak şekilde bağımsız olarak yeniden oluşturulduğu ve dağıtılan ikili dosyaların kaynakla eşleşip eşleşmediğinin doğrulanabildiği gösterildi
- Bu doğrulama, ISO’ya dahil edilen paketlerin yanı sıra ISO oluşturma sürecinin kendisini de yeniden üreterek, yalnızca paketlerin yeniden üretilebilirliğinden daha geniş bir kapsamı doğruluyor
- Yeniden oluşturma, NixOS 20.03 VirtualBox appliance’ından başlayıp
nixpkgsrevizyonu63678e9f3d3akullanılarak yapıldı ve--option substitute falseile ikili önbellek bağımlılığı kapatıldı - 2020 tarihli OVA’da veya indirilen
gitiçinde sofistike bir arka kapı olsaydı bunun hâlâ bir saldırı vektörü olabileceği, bu yüzden tamamen bootstrap edilmiş bir sistem tabanlı doğrulamanın hâlâ beklediği belirtiliyor - Minimal ISO’nun yeniden oluşturulması önemli bir kilometre taşı olsa da, geçici geçici çözümlerin kaldırılması, daha fazla kurulum medyasının yeniden üretilebilir hâle getirilmesi, düzenli bağımsız yeniden oluşturma altyapısı ve derleme kanıtı araçları sıradaki görevler
Minimal ISO’da doğrulanan yeniden üretilebilirlik
- Hydra’nın yayımladığı
nixos-minimalISO derlemesi bağımsız olarak yeniden derlendi ve bit düzeyinde aynı çıktı elde edildi - Yeniden üretim kapsamı iki eksene ayrılıyor
- ISO’ya giren tüm paketler
- ISO’yu oluşturan derleme sürecinin kendisi
- ISO derlemesi için gerekli olup ISO’nun içine dahil edilmeyen paketler de birlikte derlendi ve önbelleğe alınmış ikili dosyalara bağımlı kalınmadı
- Yeniden üretilebilir derlemeler, dağıtılan ikili dosyaların kaynağa sadık olup olmadığını ve Hydra gibi derleme hatlarında değiştirilip değiştirilmediğini doğrulayabilen bir güven yolu sunuyor
Yeniden oluşturma süreci ve sınırlamalar
- Yeniden oluşturma, yeni bir VirtualBox appliance içinde NixOS 20.03 ile başlatılarak gerçekleştirildi
- Yeterli CPU ve bellek tahsis edilip disk yaklaşık 65GB’a genişletildi
gitkurulduktan sonranixpkgsklonlandı ve63678e9f3d3arevizyonu checkout edildi- Gerekli bileşenler ikili önbellekten çekilmeden,
--option substitute falseile yerel makinede derlendi
- Süreç, bilinen sorunları aşmak için geçici önlemler içeriyor
- Tedarik zinciri güveni açısından bazı sınırlamalar sürüyor
- 2020 tarihli OVA’da veya indirilen
gitiçinde sofistike bir arka kapı olsaydı bu hâlâ bir saldırı vektörü olabilirdi - Tamamen bootstrapped bir sistem üzerinde yeniden oluşturma yapmak daha iyi olurdu, ancak henüz bu aşamaya ulaşılmış değil
- Bu konudaki ilerleme nixpkgs supply-chain security project başlığında sürüyor
- 2020 tarihli OVA’da veya indirilen
2021 duyurusu ile bu sonucun farkı
- 2021’de minimal ISO’nun %100 yeniden üretilebilir olduğuna dair bir duyuru yapılmıştı, ancak o dönemde yalnızca ISO derlemesi için gereken paketler tek tek yeniden üretilmiş, gerçek ISO yeniden oluşturmasında ise farklar kalmıştı
- Bunun nedeni, Hydra önbelleği ve ISO oluşturma biçimindeki kalan sorunlardı
- Sorunlar düzeltilirken Python 3.10’un upstream tarafındaki problem gibi gerilemeler ortaya çıktı ve ancak bu hafta tüm zincirin doğrulanabildiği bir duruma geri dönüldü
- Sıradaki adımlar; geçici geçici çözümlerin kaldırılması, daha fazla paketin yeniden üretimi ve Gnome ISO gibi diğer kurulum medyalarının yeniden üretimi
- Ayrıca düzenli bağımsız yeniden oluşturma altyapısına ve trustix gibi derleme kanıtlarının paylaşılması ve tüketilmesine yönelik araçlara da ihtiyaç var
1 yorum
Hacker News görüşleri
Kaynaktan minimal ISO’yu yeniden derlemek, kaynaktan yeniden üretilebilir şekilde derlenen bir sisteme giden yolda etkileyici bir dönüm noktası
Guix de yakın zamanda aynı yolculukta ortogonal ama aynı derecede etkileyici bir başarı elde etti: başka ikili derleyici blob’ları olmadan, tek bir yeniden üretilebilir 357 baytlık ikiliden tüm derleyici araç zincirini bootstrap etti
Belki yakında bu ikisi birleşir ve tüm dağıtımı kaynaktan yeniden üretilebilir şekilde derlemek mümkün olur
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
Pek çok kişinin anlamadığı temel nokta, çıktının %100 güvenilir olduğunu kanıtlamak değil; çıktının kaynağa %100 sadık olduğunu kanıtlamak
Yani gizli bir arka kapı gibi şüpheli bir şey bulunursa, onu her zaman kesin biçimde yeniden üretilebilir hale getiriyorsunuz
Kötü niyetli taraf açısından kaçacak da saklanacak da yer kalmıyor
357 baytlık makine kodunun tamamı elle belgelenip insanların anlayabileceği hale getirilebilir gibi geliyor
Böyle bir şey yapmadığım için aptalca bir soru olabilir ama yeniden üretilebilirliğin neden varsayılan davranış olmadığını merak ediyorum
Aynı kaynaktan iki yazılım derlediyseniz, her seferinde tamamen aynı olmalarını neyin engellediğini pek bilmiyorum
Çok fazla hareketli parça olduğunu biliyorum ama farkların nasıl ortaya çıktığını hâlâ tam anlayamıyorum
Yaygın sorunların listesine buradan bakabilirsiniz: https://reproducible-builds.org/docs/
Genel olarak işin özü, geliştiricilerin bunun yeniden üretilebilir olup olmadığını test etmemesinde
Sürüm testlerine dahil edildiğinde genelde yeniden üretilebilir durumda kalıyor
Açıkça yeniden üretilemez hale getiren başlıca örnekler arasında zaman damgaları ve yazar bilgisi var
Varsayılan yeniden üretilebilirliği örtük olarak bozan yerler de var; örneğin birçok çalışma zamanı hashmap öğelerinin sırasını tanımlamaz, derleyici de ikiliyi oluşturmak için o hashmap’i dolaşabilir
Sıradan bağımsız olmayan işler olabilir; CPU durumuna bağlı olarak biraz farklı ikililer çıkabilir ama hepsi doğru sonuç olabilir
Bazen de zamana veya ortama bağlı metadata, iş parçacıklarının çalışma sırası gibi şeyler neden olur
Bilmediğim için kusura bakmayın ama NixOS’un var olmasının başlıca nedenlerinden birinin yeniden üretilebilirlik olduğunu sanıyordum
Bu sorunların zaten çözüldüğünü düşünmüştüm
NixOS’u sadece yaklaşık 2 saat kullandım ve Hyprland’i denemek istemiştim; Hyprland biraz yapılandırma gerektirdiği için başkalarının ayarlarını alıp kullanmanın NixOS’ta diğer dağıtımlara göre daha kolay olacağını düşünmüştüm
Ama ayar bulmak da zordu; rastgele GitHub gist’lerinde 3 kadar tane buldum, hiçbiri çalışmayınca vazgeçtim
Normal dağıtımlardaki gibi tüm sistem ortamına bağlı olmadığı için çoğu durumda zaten her seferinde aynı ikili çıkar
Ancak derleme sürecinin kendisi birçok pakette belirlenimci olmayabilir; bu tek başına doğrudan tam yeniden üretilebilirlik sağlamaz
Aklınızdaki anlam, ikili paketi kolayca yeniden derlediğinizde aynı bağımlılık sürümlerini, derleme seçeneklerini vb. kullanmak
“Benim dizüstümde çalışıyordu” türü derleme hatalarının yeni baştan ortaya çıkmasına yer olmaması demek
Burada kastedilen anlam ise tüm derleme çıktılarının bayt düzeyinde aynı ikililer olması
Makine adına, derleme zamanına, paralel derlemede dosya derlemelerinin hangi sırayla bittiğine vb. bağlı olmamalı; bu taraf çok daha zor
Alışık değilseniz, “şu anda çalışan bir şey istiyorum” durumunda seçilecek araç pek değil
NixOS’ta “yeniden üretilebilir” denmesi daha çok “aynı Nix koduyla aynı program davranışını elde etmek” anlamına yakın
İnsanların Dockerfile’dan beklediğine benzer; “benim makinemde çalıştı” veya “geçen sefer çalışmıştı” sorununu çözmeye yönelik bir düzey
Buna karşılık “yeniden üretilebilir derleme”, farklı makinelerde oluşturulan çıktıların bit düzeyinde aynı olmasını hedefler
Böylece kodun belirli bir kaynak kümesinden derlenip derlenmediğini doğrulayabilirsiniz; bu da bir güvenlik katmanı sağlar
Ayar ararken hangi arama terimlerini kullandığınızı da merak ediyorum
“nixos configuration” diye aratınca https://github.com/search?q=nixos%20configuration&type=repos... gibi sonuçlar çıkıyor; sadece Hyprland’e bakınca da https://github.com/search?q=wayland.windowManager.hyprland&t... gibi epey sonuç görünüyor
https://github.com/donovanglover/nix-config adresine bakmak iyi olur
Flake tabanlı bir yapılandırma ve içinde Hyprland ile birçok iyi şey var
Mevcut hâliyle NixOS, zayıf olanlar ya da zamanı kısıtlı olanlar için uygun bir araç değil
Umarım bir gün değişir; ama dayanıp aşabilirseniz faydasını görebilirsiniz
GitHub kod aramasını kullanıp kullanmadığınızı merak ediyorum
İlgili Home Manager seçenekleri burada bulunabilir: https://mipmip.github.io/home-manager-option-search/?query=h...
Sonra GitHub’da arama yapabilirsiniz: https://github.com/search?utf8=%E2%9C%93&q=lang%3Anix+hyprla...
Bazı seçenek aramaları daha gündelik ya da daha ileri düzey kullanıcı tarafını ima edebilir
Nix / NixOS / Nixpkgs’in yeniden üretilebilirliğinin kaynağın yeniden üretilebilirliği olduğunu unutmamak gerekir
Kaynak değişirse uyarı alırsınız; ancak bu, her derlemede değişebilen ikililerin yeniden üretilebilirliğinden farklıdır
Nix / NixOS / Nixpkgs’in ikili yeniden üretilebilirliği, en azından sistematik olarak, pek iyi test edilmiyor
Guix, Arch Linux ve Debian ikili yeniden üretilebilirliği Nix / NixOS / Nixpkgs’ten daha iyi ele alıyor
Kaynaklar: https://r13y.com/ (Nix*) / https://tests.reproducible-builds.org/debian/reproducible.ht... (Debian) / https://tests.reproducible-builds.org/archlinux/archlinux.ht... (Arch Linux) / https://data.guix.gnu.org/repository/1/branch/master/latest-... (Guix, yüklenmesi yavaş olabilir; önbelleğe alınmış kopyası: https://archive.is/lTuPk)
Girdi yeniden üretilebilirliği, “girdiler için kusursuz cache geçersizleştirmesi” anlamına gelir
Nix ve Guix bunu tasarım gereği kusursuz biçimde yapar; hatta bazen gereğinden fazla yeniden derlemeye yol açar
Debian ve Arch Linux bunu ana ilgi alanı olarak görmez; belirli bir kaynak dosyası güncellendiğinde hangi paketin yeniden derleneceği sorununu manuel yeniden derleme tetikleyicileri gibi geçici yöntemlerle ele alır
Çıktı yeniden üretilebilirliği ise “derleme sürecinin deterministik olması ve her zaman aynı ikiliyi üretmesi” anlamına gelir; asıl yazının konusu da budur
Nix paketleri sandbox içinde derlediği için bu yardımcı olur, ama her şeyi çözen sihirli bir yöntem değildir
Bu açıdan Nix de Debian ve Arch Linux ile aynı gemidedir
Aslında dağıtımlar, yeniden üretilebilirliği artıran yamaları sık sık upstream’e gönderir ve diğer dağıtımlar da bundan yararlanır
Bu bağlamda https://reproducible.nixos.org verilen diğer bağlantıların karşılığıdır; Nix raporunun daha az ayrıntılı olduğuna katılıyorum, ama bu Nix’in ikili yeniden üretilebilirliğinin daha kötü olduğu anlamına gelmez
“Nix yalnızca girdi yeniden üretilebilirliğinde iyi, ikili yeniden üretilebilirliğinde kötü” şeklinde okunursa bu yanlış olur
Burada kutlanan kilometre taşı tam da bu
Bu yazı yalnızca ikililerin değil, onların ISO olarak paketlenme biçiminin de bit düzeyinde yeniden üretilebilmesinden bahsediyor
r13y.com eski durumda; eksik kalan %1’den az kısmın da hatırladığım kadarıyla upstream Python’daki bir regresyondan kaynaklandığı söylenebilir
İkililerin kendi yeniden üretilebilirliği, ISO paketlemesi hariç, zaten birkaç yıl önce sağlanmıştı
Çekirdek ISO’nun ötesindeki paketlere geçildiğinde karşılaştırma karmaşıklaşıyor
Paketlerin ele alınış biçimi ince ama bu bağlamda önemli ölçüde farklı; Arch’in AUR’unda olabilecek birçok paket Nix’te normal paket olarak yer alıyor ve çoğu -bin upstream paketi de Nix’te basitçe gerekli olmuyor
Genel olarak Nix, yeniden üretilebilir derlemeler oluşturmayı kolaylaştırır; ancak bu Nix’ten bağımsız olarak her zaman mümkün değildir ve çoğu zaman yama gerektirir
Nix’in temel paket deposunda 80 binden fazla paket varken Arch’te AUR hariç 15 binden az paket olduğu gerçeğiyle birlikte düşünülünce yüzde karşılaştırmaları pek kullanışlı değildir
Çok yaygın yanlış anlamalardan biri, Nix store yolundaki hash’in derleme çıktısına dayandığını sanmaktır; oysa gerçekte, izole bir ortamda ikiliyi derlemek için kullanılan tüm kaynaklara ve girdilere, ikili olup olmamasından bağımsız olarak bunların tamamına dayanır
Bu yüzden insanların beklediği güvenlik avantajları aynen ortaya çıkmaz; ancak buna karşılık yeniden üretilebilir biçimde derlenmeyen yazılımların da işlevler, derleyici ayarları, bağımlılık sürümleri, kullanıcı, yapılandırma vb. aynı olan makul ölçüde yeniden üretilebilir bir dağıtım biçiminde kullanılmasını sağlar
Aynı kaynaktan farklı makinelerde derlendiğinde ikilinin aynı olup olmadığını kontrol ediyor
Esas nokta, ikilinin her derlemede değişmemesi
Test yöntemi de her derlemenin farklı zamanlarda, farklı donanımlarda ve farklı çekirdeklerde iki kez çalıştırıldığını söylüyor
Görünüşe göre %85,6 yeniden üretilebilir yazıyor: https://reproducible.archlinux.org
Resmî deposunda 80 binden fazla paket olan NixOS’ta ne kadar iş gerekeceğini merak ediyorum
nixpkgs’in hedefleri ya da mevcut gerçekliği açısından bakıldığında bu hiç de doğru değil
Asıl yazı, içinde birden fazla ikili paket bulunan ikili minimal ISO’yu yeniden üretme hikâyesini anlatıyor
OpenBSD projesinin tam tersi yönde harıl harıl ilerliyor olması ironik olduğu için komik
OpenBSD’de her kurulumun kendine özgü, rastgeleleştirilmiş adres ofsetleri var
Yeniden üretilebilir derlemeler ile benzersiz kurulum hedeflerinin birbirine dik olduğunu ve aynı anda başarılabileceğini anlıyorum, ama bu ikilik hâlâ komik
Ya da program başlatılırken ofsetleri rastgeleleştirmek de yeniden üretilebilirliği korurken güvenliği daha da artırabilir
Böylece her çalıştırmada ofset değişir
Paketin kendisi yine de yeniden üretilebilir olabilir
Tüm rastgeleleştirme, paket indirildikten ve checksum doğrulandıktan sonra yerelde yapılıyor
Artık neredeyse tüm diğer Linux dağıtımlarının 90’lardan beri yaptığı gibi, bakımcılar paketleri sadece imzalasa iyi olur
Böylece herkesin derlediği kodun, bilinen kişiler tarafından gönderilip incelenen aynı kod olup olmadığını bir ölçüde bilebiliriz
İmzalama standart hâle gelmeden, değerli bir şeyi koruyan üretim amaçlı kullanımlarda Nix kullanmayı hayal etmek zor
Çoğu, paketin içeriği hakkında herhangi bir garanti vermiyor
Onların imzasından anlamlı bir güvence beklemek, kargo görevlisinden ürün desteği beklemeye benziyor
Paketin kötü niyetle paketlenmediğine inanmak zorunda da değilsiniz
Nix yeniden üretilebilir derlemeler yaptığı için, ikili önbelleğe güvenmek istemiyorsanız derivation’a bakıp kendiniz derleyebilirsiniz
Temel içeriğin kötü niyetli olup olmadığı ise nihayetinde geliştirici ile kullanıcı arasındaki bir mesele
Diğer dağıtımlar sizi bunun tersine inandırdıysa, bence bu daha çok yanıltma sayılır
Aklıma gelen istisna Tails; ama Tails, Nix kadar geniş kapsamlı değil
Görünüşe göre Debian artık bunu yapmıyor; derleme sistemi derlemeyi imzalıyor, Fedora da yapmıyor, Arch’tan emin değilim ama sanırım o da yapmıyor
NixOS derleme sistemi tüm derleme çıktılarını kendi anahtarıyla imzalıyor ve indirme sırasında imzayı doğruluyor
Paranoyak yaklaşırsanız, Nix en azından her şeyi doğrudan kaynaktan derlemeyi kolaylaştırıyor
Çok etkileyici bir kilometre taşı; bunu mümkün kılanları tebrik ederim
ISO’yu gerçekten yeniden derlerken de farklar oluşmuş; nedenin Hydra önbelleğinde kalan bir sorun ve ISO’nun oluşturulma biçimi olduğu belirtilmiş
“ISO’nun oluşturulma biçimini” nasıl düzelttiklerini açıklayabilecek biri var mı merak ediyorum
Eskiden yeniden üretilebilir ISO oluşturmaya çalışmıştım ama dosya sisteminin extent’leri deterministik belirlemesini sağlayamamıştım
Sürecin son adımı
./result/isodizininde ISO’yu oluşturuyorAradığınız şey sanırım o derlemenin çağırdığı komut; ama hangi adımı aradığınızdan tam emin değilim
Örneğin
xorrisoçağrısı burada: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-...Bunu yapmak için sistem saatini kandırmak gerekmez mi?
Zaman çoğu kez bir şekilde ikililerin içine giriyor
O kadar yaygın ki, birçok derleyici zaman damgasını kandırmak için fiilî standart değişken olan SOURCE_DATE_EPOCH’u uyguladı: https://reproducible-builds.org/docs/source-date-epoch/
Bu, Ken Thompson’ın “Reflections on Trusting Trust”ta yazdığı problemi çözmeye yardımcı olmaz mı?
Tüm sistemi kaynak koddan tamamen bootstrap edebiliyorsanız, içine arka kapı yerleştirilmiş derleyici gibi bir şeyi sokmak daha zor olur gibi
Teoride ISO’nun derlendiği ortamın içinde incelikli bir arka kapı da olabilir
Bu sorunu gerçekten çözmek istiyorsanız Diverse Double Compiling’e (https://dwheeler.com/trusting-trust/) ya da tüm ortam bootstrap’ine (https://bootstrappable.org/) bakabilirsiniz
Yazıdaki “Yukarıdaki yaklaşımda bootstrap problemi yok mu?” bölümü de ilgili
Yine de yalnızca derlemeyi yeniden üretmek bile bu tür saldırıların giderek daha az olası hâle gelmesine büyük katkı sağlar
Son dönemdeki iş nedeniyle Red Hat ekosistemi içinde bulundum
Bunun Fedora Silverblue, Ansible, Fedora Silverblue + Ansible gibi şeylerle nasıl karşılaştırıldığını merak ediyorum
Imagebuilder yeniden üretilebilirlik iddiasında bulunuyor, ancak bildiğim kadarıyla çoğu rpm paketini kaynaktan değil ikili olarak kuruyor
Bu yüzden tüm girdi paketleri de yeniden üretilebilir değilse, katı anlamda yeniden üretilebilirlik sayılmaz
Paketleri kaynaktan derlemek, dağıtım imajı oluşturmak ve yeniden üretilebilirliği ele alan açıklama size pek anlamlı gelmediyse, muhtemelen ana hedef okuyucu kitlesi siz değilsiniz
Buna karşılık Ansible, işletim sisteminin izlemesi gereken adımları belirtir
Silverblue ve Nix, Linux dağıtımı olmaları dışında birbirinden bağımsız kavramlar
Silverblue, değişmez bir ana makine üzerinde yalnızca konteynerler kullanarak yazılım dağıtım şeklini değiştirmeye yönelik bir deneme
Jsonnet ve durum takibi kullanarak Nix’i bir ölçüde taklit eden bir Ansible alternatifi arıyorsanız Etcha’ya bakmaya değer: https://etcha.dev
Nix değişmezdir
Yeni değişiklikler tamamen baştan oluşturulur ve derleme başarılı olduktan sonra ancak tüm paketler mevcut sisteme “sembolik bağlantı” olarak bağlanır
Fedora Silverblue ostree tabanlıdır https://github.com/ostreedev/ostree
Kök ağacı için git’e benzer şekilde çalışır, ancak değişiklikleri uygulamak için tüm sistemi yeniden başlatmak gerekir
Nix, paketleri sembolik bağlantılarla bağlama yöntemi kullandığından sistemi yeniden başlatmaya gerek yoktur
Daha ayrıntılı açıklama burada: https://dataswamp.org/~solene/2023-07-12-intro-to-immutable-...