Kilka dni temu Internet obiegła informacja, że do dość popularnej (ponad milion pobrań) wtyczki Social Media Widget dostał się złośliwy kod, który wyświetlał na stronach użytkowników link reklamowy. Na reakcję moderatorów repozytorium trzeba było czekać cztery dni – niby nie długo, ale nie zmienia to faktu, że spora grupa właścicieli witryn zdążyła już zainstalować aktualizację wtyczki i tym samym dołączyć swoje serwisy do bezpłatnej sieci reklamowej.
To niestety nie pierwszy tego typu incydent. Oficjalne repozytorium WordPressa, jedyne (teoretycznie) w pełni zaufane źródło rozszerzeń, po raz kolejny okazało się nie do końca bezpieczne. Co gorsza, istnieje kilka innych problemów, z którymi borykają się ostatnio użytkownicy repozytorium.
Jak twierdzi Samuel Wood (znany lepiej jako Otto), autor wtyczki nie był do końca odpowiedzialny za tę sytuację – złośliwy kod wprowadziła osoba, do której miał zaufanie, a która tego zaufania nie była (jak widać) godna. Wyjaśnienia okazały się na tyle wiarygodne, że rozszerzenie wróciło do repozytorium, co w takich przypadkach się z reguły nie zdarza.
Kto zawinił?
Poza osobą, która wykorzystała zaufanie autora wtyczki – nikt. Winą za tę sytuację można obarczyć twórców zasad publikowania rozszerzeń w oficjalnym repozytorium.
Jak wygląda proces akceptacji szablonów?
Zacznę od tematu z pozoru mało związanego z opisywaną sprawą, czyli procesu publikacji szablonu w oficjalnym repozytorium WordPressa. Każdy zgłoszony motyw jest weryfikowany przez jednego z moderatorów pod kątem zgodności z wieloma wytycznymi. Wytyczne te zawierają szereg wskazówek dotyczących jakości kodu, funkcji szablonu, kompatybilności i wielu innych, istotnych rzeczy. Oczywiście nikt nie sprawdza ręcznie szablonów, które mogą zawierać kilkadziesiąt (lub więcej) plików – znaczną część testów wykonuje się za pomocą zestawu wtyczek.
Co ciekawe, weryfikacji podlegają również funkcje szablonu – jeśli w motywie znajdują się elementy, które powinny znaleźć się we wtyczce, to zostaje on odrzucony.
Po zatwierdzeniu szablon trafia do repozytorium i staje się dostępny do pobrania. Jeśli autor chce zaktualizować motyw, musi przesłać nowe wersje plików do repozytorium SVN (znajdującego się na serwerach WordPressa), a następnie zgłosić nową wersję do weryfikacji. Dzięki temu sytuacja, jaka miała miejsce w przypadku wtyczki Social Media Widget, nie ma szans wystąpić w katalogu szablonów.
Aktualizacje zaakceptowanych wcześniej szablonów są testowane głównie na podstawie różnic w kodzie (diff), dzięki czemu cały proces nie zajmuje zbyt wiele czasu, a jednocześnie pozwala na wychwycenie zmian, jakie zostały wprowadzone przez autora. Mimo że w weryfikację motywów zaangażowanych jest sporo osób, to nie ma co liczyć na szybką odpowiedź – codziennie pojawia się bowiem co najmniej kilkanaście nowych zgłoszeń, a moderatorzy wykonują swoją pracę na zasadzie wolontariatu.
Jak wygląda proces akceptacji wtyczek?
Z jakiegoś powodu proces akceptacji rozszerzeń różni się znacząco od procesu akceptacji szablonów. Autor wypełnia specjalny formularz, w którym podaje między innymi link do pliku ZIP zawierającego kod wtyczki. Moderatorzy sprawdzają zgłoszone rozszerzenie pod kątem zgodności z wytycznymi, a następnie, jeśli wszystko jest w porządku, zakładają dla niego katalog w repozytorium SVN.
I tu pojawia się najistotniejsza różnica pomiędzy procesami zatwierdzania wtyczek i szablonów: nikt nie weryfikuje tego, co trafia do repozytorium podczas aktualizacji. Autor wrzuca zmodyfikowany kod wtyczki do SVNa, po czym automatycznie trafia on do repozytorium rozszerzeń (i – w formie aktualizacji – do wszystkich użytkowników). Jak widać, pole do nadużyć jest ogromne. I właśnie tą drogą do katalogu trafiła felerna wersja wtyczki Social Media Widget – moment, w którym złośliwy kod dostał się do repozytorium, jest doskonale widoczny.
Wielu blogerów piszących o WordPressie zachęca do sprawdzania wtyczek przed instalacją lub aktualizacją, wymieniając nawet nazwy narzędzi, które mogą w tym pomóc. To nie jest żadne rozwiązanie, szczególnie dla użytkowników nie posiadających wystarczającej wiedzy technicznej – oni chcą po prostu używać WordPressa, którego wybrali między innymi (albo głównie) dlatego, że jest prosty w obsłudze i nie wymaga od nich zgłębiania tajników programowania.
Problemów jest więcej
Niestety, o ile proces weryfikacji szablonów jest dość szczelny i rzadko zdarza się, że do repozytorium trafi coś, co trafić tam nie powinno, o tyle w przypadku wtyczek jest inaczej. Z racji prowadzenia niniejszego bloga instaluję i sprawdzam bardzo dużo rozszerzeń (zarówno nowych, jak i starszych) i niezmiernie często trafiam na takie, które nie są zgodne z oficjalnymi wytycznymi – i to w kwestiach fundamentalnych. Zdarza się nawet, że wtyczki nie da się w ogóle aktywować, bo zawiera błędy. Ja sobie z tym poradzę, ale co ma zrobić zwykły użytkownik, do którego było nie było kierowany jest WordPress?
Drugim problemem jest traktowanie oficjalnego repozytorium jako tylko i wyłącznie kanału promocyjnego. Nie widzę nic złego w tym, że ktoś chce zarabiać na wtyczkach dla WordPressa. Nie widzę również problemu w tym, aby do repozytorium trafiały rozszerzenia posiadające płatną, bardziej rozbudowaną wersję. Ale widzę problem w momencie, gdy darmowa wersja wtyczki składa się w 20 procentach z działających funkcji i w 80 procentach z funkcji nieaktywnych, dostępnych tylko w płatnej wersji PRO, przy czym w opisie wtyczki nie ma o tym ani słowa, a zrzuty ekranu prezentują pełną wersję rozszerzenia. To po prostu nieuczciwe wobec użytkowników, którzy zachęceni opisem zainstalują wtyczkę tylko po to, aby za chwilę ją usunąć (a statystyki pobrań rosną). Zrozumiem ludzi, którzy się ze mną w tym momencie nie zgodzą, ale uważam, że tego typu rozszerzenia nie powinny w ogóle trafiać do oficjalnego repozytorium.
Rozwiązanie problemu
Dostosowanie zasad weryfikacji wtyczek do tych panujących w repozytorium szablonów byłoby moim zdaniem wystarczające. Alternatywne repozytoria, takie jak na przykład WP App Store, są świetne jako dodatek, ale nie są w stanie zastąpić oficjalnego katalogu – głównie dlatego, że dostęp do tego drugiego jest wbudowany w WordPressa, a ilość dostępnych w nim rozszerzeń jest po prostu przeogromna.