opiniowanie pakiwtow : mk ][ ;)

[Paweł Kołodziej]

Dnia Mon, Jan 15, 2001 at 12:37:57PM +0100, Michal Moskal napisał(a):
> Łukasz zaproponował podpisywanie opini. Ogólnie jest to
> niezły pomysł, ale wikłanie w to gnupg może okazać się
> kłopotliwe.  Pozatym nie potrzebujemy chyba tego poziomu
> bezpieczeństwa (tzn. żaden rząd ani mafia nie czycha
> na nasze opinie ;).  Proponuje prostsze rozwiązanie:
> robimy jakiś iface do dodawania userów przez CGI tylko
> po HTTPS, tam podaje się imię, nazwisko, profil maszyny,
> email etc. Ważny jest login i hasło. To hasło będzie
> potrzebne w dwóch miejscach.  Jedno to ewentualna zmiana
> dancyh (przez ten sam iface-CGI), drugie to składanie
> opini. Idea jest prosta, na końcu każdej opini (lub pakietu
> wysyłanego do serwera) dodajemy hash MD5 loginu, hasła i
> pakietu. Server również posiada te informacje, więc może
> je sprawdzić. Pozatym można robić opinie offline i wysłać
> jakoś potem (tzn. nie ma dialogu klient-serwer jeśli chodzi
> o autentykację).

Jasne. Mysle że wystarczy cokolwiek.

> 
> <malekith w nirvana:19:31:~>% rpm -qa | wc -lc
>     768   13142
> <malekith w nirvana:19:31:~>% rpm -qa | gzip | wc -c
>    5481
> <malekith w nirvana:19:31:~>%
> 
> To znaczy że rozmiar dodatkowych informacji jakie trzeba
> będzie wysłać razem z opinią wcale nie jest taki duży i
> chyba można je wysyłać z każdym raportem.

Nawet jeśli nie zajmuje to dużo to wprowadza to duży bałągan. Jeśłi chcę
wiedzieć czy nowy php działa, to nie interesuje mnie którą wersje xterm'a
mieli użytkownicy którym on działał. Bardziej interesujące będzie
informacja o glibc'u, apache, itp. Czyli pakietach bezpośrednio bądź też
pośrednio wymaganych przez php.

> Klient musi mieć informacje o kategoriach w jakich
> ocenia się pakiety. Taka lista miałaby pewnie
> kilkanaście/kilkadziesiąt kilo po skompresowaniu (tzn. o
> wszystkich pakietach). Dodatkowo klient powinien mieć
> możliwość updatowania jej jakoś nie w całości. Widze to tak
> że każda zmiana (dopisanie/skasowanie kategorii) ma kolejny
> numer, klient wysyła numer ostatniej zmiany jaką miał,
> a serwer liste od tego numeru. Tu już nie podołamy mailem.

Wszytko ok. 

> Mam też niezbyt oryginalny pomysł na nazwe całego systemu:
> "imho" ;)

No własnie ! Najwyższy czas ogłośić konkurs na nazwe ! (wkońcu za jakiś
czas trzeba będzie założyć modół w repo).

> Oglądałem libxml. To jest naprawde pokręcone, 

Doczytałem tylko do miejsca w którym pisali że supportuje DOM'a więc
wszystkio powinnobyć ok.

> pozatym
> jest jakoś związane z gnomem.

Chyba jest tylko używane w gnome.

> Ale pewnie da się coś
> z tym zrobić. Co do gnupg to nie ma czegoś takiego
> (przynajmniej ja nie widziałem) jak libgnupg. Trzeba by
> się fork()nąć i uruchomić gpg. Potem prawdopodobnie trzeba
> by zapytać o hasło. Tutaj pojawia się kilka problemów bo
> gpg to program o bezpieczeństwie wojskowym, (alokowanie
> nie-swapowalnej pamięci etc.)  a szczerze, wątpie w taki
> poziom bezpieczeństwa naszego klineta. Czemu user miałby
> mu tak od razu wierzyć i podawać hasło do swojego klucza?

Jasne. Chodziaż mutowi ludzie wieżą. Ale chyba na początek PGP to trochę
za dużo. IMHO wystarczy podawanie numerka użytkownika.

> Aha, i czy na pewno chcemy klient == wuch? Znaczy tak tylko
> się pytam ;)

Nie. Jeśli odbże zdefiniujemy teraz protokól komunikacji, to klientem może
być nawet pan Henio piszczący do mikrofonu (patrz historia o "bytecode").
Tylko IMO najłatwiej to będzie przynajmniej początkowo rozwijać na bazie
wuch'a. Ale oczywiście używanie funkcjonalności raportowania nie obliguje
do używania pozostałej.

> 
> 
> -- 
> 
>                              Michał Moskal <malekith w pld.org.pl>
> 
> 5191204625270805457964695575480234779108160500582132743089099204
> 5387169364764370076473597425941183680741973762154745366983057996
> 3022327445184252093714797111892347913483105724113222069964409702
> 905357106994771308266205

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
,,O ile nam wiadomo, komputer nigdy nie popełnił niewykrytego błędu.''
                                                 -- Weisert