[Gelistirici] Aksayan süreçler

[Eren Türkay]

On Sat, May 08, 2010 at 08:33:08AM +0300, Ali Işıngör wrote:
> Bu cevaptan şunu anlıyorum:
> 
> Güvenlik politikamızda ciddi sorunlar var.

Güvenlik politikamızda ciddi bir sorun yok. Sadece thunderbird'den yola
çıkarak böyle bir şey söylemek gerçekten mantıklı değil. Evet, bazı
konularda olan sorunların farkındayım. Bu sorunların giderilmesi için
süreci tam olarak otomatize edecek birtakım çözümlerim var ancak bu
çözümlerin hayata geçirilmesi için ekip içerisinde var olan iş
yoğunluğunun biraz hafiflemesi gerekiyor.

http://bugs.pardus.org.tr/show_bug.cgi?id=12600
http://www.mozilla.org/security/announce/

30 Mart'da Mozilla advisory yayınlamış. 6 nisanda bugzillamızda süreç
takip edilmeye başlanmış. Bu 6 gün içerisinde de bugzilla girdisine
gördüğünüz CVE-ID atamaları yapıldı. MITRE tarafından yapılan
bu CVE ID atama işinin linux dağıtımları ile ilgili bir bağlantısı yok.
Bu atamalar yapıldıktan sonra linux dağıtımlarının haberi oluyor.
MITRE'nin ne zaman atadığına bakarsak tarih olarak 4-5 Nisan'ı görüyoruz.
Bu da demektir ki 1 gün sonra bu açıkları takip etmeye başlamışız...

21 nisanda paket güncellenmiş ve depoya girmiş. Bu konuda Ozan'ın
yazdığı e-posta gayet açıklayıcı. Thunderbird paketinin aktif olarak bir
bakımcısının olmadığı zor bir paket..

"21 nisan - 7 mayıs tarihleri arasında ne oldu?" diye sorarsanız, sürecin
burada aksadığını ve sorunun burada olduğunu söyleyeceğimdir. Gördüğünüz
üzere, hatanın bugzillada takip edilmesinde ve var olan açıkların
tarafımızca bilinmesinde herhangi bir problem mevcut değil. Bu da,
bugzilla sürecinin otomatize edilmesinin bir ürünü. Şu anda sürecin "yarı
otomatize" dememin de sebebi bu.

Paket depoya commit edildikten sonra depo yöneticisine "şu paketler
düzeltildi, derlenmesi lazım" demem gerekiyor. Bu otomatize bir halde
değil ve insan faktörü çok önemli bir rol oynuyor. Bir güvenlik açığını
kapatmak gerçekten dışarıdan göründüğü kadar "sürüm atlattım, oldu" gibi
değil. Diğer dağıtımların ne yaptığına, kodun hangi sürümde, ne zaman
ortaya çıktığına, hangi sürümleri etkilediğine, bu paket sürümlerinin
hangi pardus sürümünde olduğuna, bu sürümlerin açıktan etkilendiğine
bakmak yoran bir süreç. Bu süreç sonunda commit ettikten sonra bir de
derlenip derlenmediğinin takibinin yapılması gözden kaçabiliyor. Bu durumda
olduğu gibi..

Dediğim gibi, süreci tam olarak otomatize edecek ve daha sağlıklı
çalışmasını sağlayacak çözüm(ler) mevcut. Bunlar hayata geçirildiğinde
yukarıda bahsettiğin sorunlar ortadan kalkacak ve çok daha reaktif
olacağız.

Umarım açıklayıcı olabilmişimdir.

-- Eren