builder i sygnowanie pakietów *.srpm/ *.rpm

[Tomasz Kłoczko]

On Thu, 27 Mar 2003, Witek Kręcicki wrote:
[..]
> > Dlatego pojawił się pomysł żeby oprócz test i drzewka podstawowego 
> > pakietów pojawił się jeszcze punkt pośredni który jest włąsnie 
> > eksportowany na maszynkę podpisującą pakiety. Pzrekładanei pakeitów z test 
> > do punktu pośredniego powinno odbywać się na zleceni (podaje sie nazwę 
> > pakietu źródłowego, który jest pzrerzycany na zlecenie a dodatkowo z crona 
> > chodzi skrypt wyszukujacy w katalogach z pakietami buinarnymi wszystko co 
> > powstało z teg pakietu).
> czy nie byloby choc troche bezpieczniej gdyby pakiety byly najpierw
> 'presygnowane' przez chociazby Ciebie czy kogokolwiek kto je przerzuca i
> dopiero kiedy 'signer' potwierdzi Twoja/RMF'a/whatever sygnature to
> podpisuje pakiet. Wykluczy to i pomylki i niebezpieczenstwo kiedy ktos
> sie na ep09 dostanie.

Sprawa nie jest prosta. Wiem o co Ci chodzi ale niewiem jeszcze jak na to
odpowiedzieć .. porostu musiałbym to przemyśleć :>

Tak na żywca ..

Z jednej strony trzeba będzie dążyć na dłuższą metę do separacji ftp i
sing hosta, a także builderów bezpośtrednio od zasobów developerów czy 
dosepu poprzez shell sesję.
Temu ma także słuzyć założenie nowej automatyki że _wszsytkie_ operacje na
builderach i reszcie automatyki przeprowadza się tranzakcyjnie co separuje
potencjalne niebezpieczeństwo (o czym juz pisdałem keidyś).
W takim rozwiązaniu pójście ścieżką jaką nakreślasz choć obecnie sensowane
straci (raczje) kompletnie rację bytu.

Najprościej perwne rzeczy zabezpiecza się niestety fizycznie i oparcie się
o to założenie na pewno powinno być coraz bardziej widoczne w
infrastruktórze jaką używamy.

Zakładając, że prędzej czy później taka separacja i zabezpieczenie poprzez
sirodki czysto fizyczne nastąpi można peróbować z jednej strony akceptować
ryzyko jakie istnieje obecnie a jednoczenie uważać zeby nei powiększać
puli niebezpieczeństw wobec braku fizycznej separacji, a z drugiej strony
pozwoli to na takie przekonstruowywanie automatyki żeby wykorzystywała ona
właśnie założenie o fizycznych podstawach bezpieczeństwa całości.

Myślę ze jedno z drugim w pewnym momencie jednak się zbiegnie.
Na pewno po Twoim liście powinno być bliżej do tego momentu ponieważ już 
wyartykuowane została ta kwestia i wiadomo do czego konkretnie należy 
dążyć.

Jeżeli coś przy tak określonym celu długofalowym mozńa poprawić i jeżeli 
mozna będzie coś zrobić żeby tymczasowo poprawić sytuację to oczywiście 
należy to wdrożyć. Dyskusja na temat tego jakie minimalne siorodki należy 
przedsięwiąć w krótkiej skali czau żeby zmaksymalizować efekty tychże 
zmian/lkorekt jest otwarta (chwilowo jak napisałem musże sam takze 
potrzebuję sie nieco zastanowić).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*