pld sec team (fwd)

[Krzysiek Taraszka]

On Sun, 8 Sep 2002, Blues wrote:

> On Sun, 8 Sep 2002, Krzysiek Taraszka wrote:
> > Druga rzecz. Trzeba zrobić listę wszystkich pakietów w pld mających
> > bezpośredni wpływ na bezpieczeństwo. Innymi słowy - wszystko co ma
> > suidy/sgidy i wszystko co robi za demony.
> 
> Co taka lista da?

Hmm, potencjalnie ustawi priorytety pakietow ...
 
> > Ostatnia rzecz. Metodologia taka, że ewentualne ciekawe posty z
> > pld-sec-bulk są forwardowane na pld-security, po czym omawiane. Problem
> > tylko w tym, że takie omawianie polegałoby także na dokładnym omówieniu
> > zagrożeń dla pld wynikających z danej dziury (czyli np. czy są
> > eksploity, czy one dają roota, etc). Innymi słowy specjalna oferta dla
> > script-kiddie - heterogeniczne środowisko (pld), oraz informacje o
> > wszystkich dziurach w nim zawartych (wraz ze szczegółowym omówieniem co
> > i jak) i to wszystko *zanim* światło dzienne ujrzą poprawione paczki!
> > Chyba wiesz do czego zmierzam? Taka lista miała by prawo istnieć tylko
> > jako wewnętrzna lista zaufanych deweloperów (np. minimum 6 miesięcy
> > stażu or sth), a na zewnątrz mogłyby być wypuszczane tylko advisory
> > (specjalna lista stworzona w tym celu na którą mógłby się zapisać każdy
> > admin).
> 
> Taki model powoduje trochę zamknięte działanie. Chodzi o wciąganie nowych 
> osób, to nie będzie ładnie sie toczyło...

No tak, jakie masz lepsze rozwiazanie ?
 
> > Szczegóły są do ustalenia (czyli na przykład, jeśli dana dziura jest
> > znana, a jeszcze nie załatana, a jest znany workaround to wypuszczamy
> > advisory z owym workaroundem). Oczywiście jeśli to ma być z prawdziwego
> > zdarzenia to jeszcze trza by mieć własny katalog na eftepie (dostęp dla
> > sec-teamu z pominięciem kloczka), wpis do poldka (tzn żeby poldek -n
> > ra-sec upgrade * działało jak trzeba), oraz własny builder/możliwość
> > posyłania zleceń na buildery poza kolejką.
> 
> Nie w ten sposób. własny builder to będzie baaardzo zły pomysł (buildery 
> mogą się między sobą rozjeżdżać.... chociażby).

Hmm, e-e.
Raczej chodzilo by o cos na wzor security.pld.org.pl gdzie byly by pakiety 
"gorące". Potem recznie do 1.x byly by przezucane.
 
> Tutaj powinien aktualny być zmodyfikowany (kiedyś o tym myślałem), aby 
> były 2 kolejki: normal i privileged. Normalnie wszystko do pierwszej 
> kolejki idzie. Jeżeli coś będzie podpisane odpowiednim kluczem PGP to 
> trafia do kolejki privileged. Budowanie będzie w pierwszej kolejności 
> wykonywane z tej właśnie kolejki oraz będą informowane odpowiednie osoby 
> mailem, że coś się tam pojawiło. rezultat budowania powinno trafiać do 
> innego katalogu niż test, np. privileged-test i _automatycznie_ 
> przegenerowywane byłyby tam indeksy poldkowe... To byłyby quick security 
> fixes dla niecierpliwych, ale nie przetestowane jeszcze.
> Przerzucanie do updates powinno mimo wszystko odbywać się ręcznie.

Po co ?
builder Ra zostanie "przymrozony" (dla 1.0->1.x).
Builder dla 2.0 chyba bedzie nowy.
wg. zalozen dla Ra będa szly sec fixy, bugfixy, wiec raczej kolejkowanie 
dla 1.x nie bedzie potrzebne ...
 
Krzysiek Taraszka			(dzimi at pld.org.pl)