Pozdrav,
zanima me kako je rješeno pitanje sigurnosti kod composera. Laički si razmišljam da ako koristim taj sustav da instaliram neki paket i on mi automatski nakači svakojakog dependencya u projekt …kako ja zapravo mogu znati da nisam nakačio nešto maliciozno? Ili nekakav back-door?
Hvala.
Nema tu sigurnosti. Vec je bilo slucajeva distribucije takvih zlih paketa putem npm-a i pip-a
Tako mi se i učini.
Definitivno zajednici fali jedan sigurnosni layer koji bi funkcionirao po principu da kada dodaješ neku komponentu, da joj određuješ permissione koje ista može raditi.
Tj. komponenta bi trebala pitati za permissione iz onog range-a posla kojeg planira obavljati. Analogno po principu kada se dodaje novi app na android.
Ista stvar fali i na windowsu. Tehnički svaki puta kada netko instalira neki program (ako nema povjerenje u isti) …gaće su mu na štapu i može se samo nadat da taj program neće činiti na računalu ono što bi mogao.
S obzirom koliko mi je muke zadao neki virus na WP-u, bit će jako veselo kada se neki virus dovoljno proširi putem Composera i tek tada krene u akciju. Sretno svima bilo. 
Znači nešto te dobro “gazalo”! 
Dok ne stekneš iskustvo i poznavanje paketa odnosno njihovih autora (kroz grupe, blogove, konferencije…) instališi pakete koji imaju iznad 1000 zvjezdica i nećeš imati problema.
Uzmi ovo zdravo za gotovo. Alternativa ti je da linkuješ github repo ovde i dobiješ odgovor da l’ da koristiš taj il’ neku drugu opciju.
Krivo. “gazalo” je svršeni glagol, a kod mene se radi o ne svršenom xd. Još uvijek gazi, heh.
Ima đubre nekakav backdoor i svako malo se pojavi sa drugim idejama…a kada pusti novu ideju, popada xx projekata koji su zavisni.
Još je sada i dobro, prije je to bilo na nekakvom hostingu koji nije imao sigurnosnu barijeru između projekata, pa se ta malicioznost raširila na 50-ak projekata.
Sada je sve preseljeno na sigurniji server, pa pod malicioznošću klelknu samo oni projekti koji unutar sebe imaju propust.
Ja doduše nisam te projekte pravio…i ti koji su problematični su napravljeni u WP.
No onako mi logika proradila, tako se netko može ugnjezditi preko Composera. Džabe tu 1000 zvjezdica, ako je netko napravio korisnu komponentu gdje mu je cilj se samo što bolje raširiti…kako bi tek onda aktivirao svoju namjeru. Naravno da mu je onda početna faza upravo skupljanje zvjezdica i što bolje širenje “društvom”. Vrijeme inkubacije je njegova volja. 
Na koji nacin ovo rijesava navedeni problem ? Ako ti paketu npr. ne dozvolis da ima bilo kakvu interakciju sa fs modulom, ti i dalje ostavljas prostor za backdoor na drugom mjestu.
Github prati neke sigurnosne propuste u paketima, i samim tim ti salje obavijest ako se pojavio neki paket koji ima sigurnosni problem
Ali ono sto ti je @tpojka rekao je u biti glavno.
Pa ako si dodao komponentu koja ti formatira samo datum…nema te što tražiti permission za slanje emaila, ili za curl ili za read drugih file-ova, kamoli permission za file write.
Svaka komponenta ima svoj zadatak i permissioni bi trebali biti u skladu sa time. A ako se uzima komponenta koja će odrađivati škakljiviji dio posla, onda se ona bolje u startu razmotri što radi…i takve komponente bi očito morale imati svoj social-trust, zvjezdice…poznatog autora itd…
A ovako nisam lud da ću ići koristiti neku simple komponentu koja ništa od tog social proof-a nema, ako nemam nikakvu garanciju na razini kompajlera što će ta komponenta moći raditi.
Ok, ovo vidim kao potvrdu da sam bio u pravu oko problematike … jer iskreno nisam bio siguran jel tom problemu nekako doskočeno.
Naprosto mi je bilo nevjerovatno da su svi na composeru … a ono je uže oko vrata… i samo je pitanje kada će i koga stenuti.
Ono najgore, dobro planiran haker bi u jednom momentu mogao naguziti cijelu zajednicu koja je na composeru… a onda će svijet imat problem…
Grdo je ako naguzi i composer populacij… a taj virus bi mogao po sereverima proći i dalje od malicioznih stranica sa composera pa zahvatiti i dobar dio ostatka ekipe sa tih servera. (Neki serveri jednostavno nemaju zaštitu da takvi virusi pređu sa jedne web stranice na drugu)
Morat će se očito desiti jedna računalna Corona da ljudi shvate problem koji imaju.
Koliko mi se čini, gornji pristup ne rješava problem… jer virus da bi pravio štetu, on se ne mora odavati. Može biti i karaktera da samo čupa podatke i prosljeđuje ih trećoj strani.
Ako će praviti i veliki darmar… prvo može biti pritajen koliko god želi i onda nastupiti kada se zadovolji brojem korisnika na koje se nakačio …
Uglavnom: PHP + suradnja sa nepoznatim autorima = sigurnost 0.
Jeste, taj paket je samo potvrda, a nikako rjesenje problema.
Prije će se desiti da napraviš odličan paket koji će sam zajednica ostaviti na korištenje uprkos brisanju sa repozitorijuma (ne dozvolivši autoru da ga obriše) što se desilo brojem i slovom jednom, nego da zombi korisnici počnu koristiti maliciozan kod. To bi trebalo da je abstrakt ove i ovakve problematike.
Nisam bas razumio, tvrdis da nema opasnosti ako smo oprezni ili nema opasnosti uopce?
@ognjen
Uzmi vrijeme koje bi ti bilo potrebno za pisanje solidnog paketa.
Uzmi sad vrijeme koje bi ti bilo potrebno da uradiš PR (peer review) istog paketa.
Kad oduzmeš drugo od prvog vidiš kol’ko vremena štediš. Il’ drugim riječima, dovoljno je da počneš čitati nečiji kod da znaš da l’ ćeš ga upotrijebiti il’ ne.
Ovo što sam nazv’o zombi korisnikom je neko k’o upotrebljava repo kod bez ulaženja u to kakav je. Da l’ je nekom potrebno da pročita kompletno sav kod il’ tek da baci pogled na composer.json/package.json da bi’ ga mog’o u trenutku odbaciti k’o neprihvatljiv - ostavljam individualnoj odluci. Korištenje paketa, bez da se zna šta je unutra je manje više poput korištenja copy/paste Stackoverflow odgovora.
I nikad zgoreg ponoviti: NIKAD koristiti root (ili ma kojeg sa administratorskim ovlaštenjima) korisnika za install/update paketa.
Ah dobro, znaci moramo biti oprezni.
Jest da nije copmoser…evo stanja projekta na kojem upravo radim,
Pa eto, upravo se uklapa u ovo što sam rek’o: iako arbitrarno uzeto, ne mora se gledati 2551 paket koda već tek njih 8.
Što se mene tiče, nema pravilne organizacije bez sustava koji će nadgledati i kontrolirati organizaciju.
Znakovi za ograničenje brzine su lijepa ideja, ali bez policajca koji će nadgledati oni su samo slovo na limu.
Još efikasnije (nikome draga) je kamera koja će automatski kontrolirati brzinu vozila.
Ovo što tpojka govori o ručnoj provjeri paketa, je još malo više zaostalo od policajca koji kontrolira brzinu…jer tko bi sve “ceste” nadgledao u real time.
Jedino tako ispravno rješenje je postaviti kamere.
U svijetu programiranja to su programi koji će vršiti statičku analizu coda i i razumjeti što taj code sve može u sustavu.
Jer nije isti code koji dira u file system i onaj koji ga ne dira. A to statička analiza lako uočava.
Nadalje, kada imamo statičku analizu coda, onda možemo i dati dopuštenje tom komadu coda da dira nešto ili ne dira. To su dozvole koje android pita korisnika hoće li dopustiti nekoj aplikaciji prilikom instaliranja aplikacije. Gdje android nikada neće dopustiti nekoj aplikaciji da u sistemu radi više od dobivenih dozvola…a to Android može jer je on container te aplikacije.
U PHP svijetu, taj modul za statičku analizu mora isto biti cotnainer kroz koji će taj ugrađeni dio code-a djelovati. I to se svakako može postići…tj. ja sam to postigao sa svojim PHML-om: PHML - preparsed PHP
Moj PHML dakako u ovoj fazi nije usavršen alat, ali sam zasigurno uvjeren da je to puno ispravniji put (od gore navedenog) kojim se ovaj problem rješava. Danas sutra će već niknuti takve tehnologije, jer mi se još nije desilo u mojih 15 godina programiranja da nisam napravio neki alat koji zatim nebi nastao unutar neke veće korporacije…utjeran do savršenstva.
Tako da prije ili kasnije, stići će već nečiji PHML na mala vrata… ja se dotad igram sa svojim.
Isto valja imati na umu da se ti paketi konstantno nadograđuju. Mogu biti i takvi paketi koji nadograđuju sami sebe bez pitanja. …i to je sve legit, jer zašto ne.
Ali s obzirom na to metoda da se ručno pogleda što neki code ima ili nema …pada u vodu, jer to svakako ne možemo raditi u real time…
Jel, da ti je netko prije koju godinu rekao da ćemo u trgovine ulaziti jedan po jedan, sa maskama na licu…da neće raditi kafići niti pola drugih poslovnica…
…ti bi vjerovatno odgovorio nešto u stilu:
Okači to mačku o rep. Sranje se nije desilo dok se nije desilo. Ako shvatimo kako se može desiti, imamo prednost da radimo na prevenciji po tom pitanju.
Sve drugo je guranje glave u pijesak kao što to vole nojevi raditi.
Što je najgore, ovo nije problem samo PHP-a, ovo je generalni sigurnosni propust cijelih windowsa.
Tako reći…ti kada instaliraš neki app na windowse…ti nemaš pojma što će sve taj app na tvom računalu raditi.
Taj app ako želi…može pretraživati tvoje foldere i tragati za zapisima o BTC adresama/ključevima. Nema baš nikakvog filtera gdje je korisnik instaliranu aplikaciju limitirao na neki folder unutar koje ona smije “živjeti”.
A samo da je to…već bi se puno napravilo…
Slično kod PHP-a, već bi se puno postiglo da dodani paket (na razini php-a je to includana skripta) …da se njoj kod includanja mogu definirati ograničenja po kojem djelu fileSystema smije pisati.
Već bi ju to ograničilo u njenoj malicioznoj ideji da ostale skripte editira tj. da ih zarazi sa svojim snippetima code-a.
NHF, al’ ti apsolutno nemaš pojma o čemu pišeš. Ni u najgorim trash filmovima se ne može vidjeti akrobacija i put logike kojom si povez’o mjere predostrožnosti u stanju pandemije sa običnim PR-om koda. Iskren da budem ni nemam vremena dodatno čitati neuspjele pokušaje istih.
Naravno za paranoju tog tipa ostaje mogućnost da se napiše aplikacija od - do.
Koja će opet biti manje sigurna od onog što su stotine hiljada inžinjera nadogradile.
Za ove instalacije proprietary aplikacija/programa (i.e. onih koji nisu open source) se djelimično slažem i rješavam tako da ne instališem neprovjerene aplikacije u kompjuter. Open source je u tom smislu s jedne strane sigurniji. Al’ vrtim odgovor ukrug. Kome to nije jasno, neka radi kako misli da mu je bolje. Opet, instalacija neprovjerenog koda, a da se nije pročitalo šta radi, je opasna i na tome ću se zaustaviti.
