Ulepsz przechodnie zależności za pomocą PNPM: Napraw luki w zabezpieczeniach bez psucia rzeczy
Naprawianie luk w zabezpieczeniach może być frustrującym zadaniem, szczególnie gdy dotyczy przechodnich zależności. Dowiedz się, jak je zaktualizować bez wpływu na swoje bezpośrednie zależności.
GaoFounder
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
W dzisiejszych czasach luki w zabezpieczeniach są powszechnym problemem w programowaniu. Na szczęście mamy narzędzia takie jak GitHub Dependabot, które pomagają nam utrzymywać nasze zależności na bieżąco dzięki zautomatyzowanemu wykrywaniu i pull requestom.
Jednakże nie zawsze działają one zgodnie z oczekiwaniami. Ponieważ niektóre zależności są przechodnie, ich aktualizacja może być trudnym zadaniem dla tych narzędzi, ponieważ nie wiedzą one, jaki wpływ będą miały zmiany i jakie decyzje podjąć w przypadku konfliktów. Musimy radzić sobie z tymi sytuacjami ręcznie.
Oficjalne polecenia, takie jak pnpm up, namieszają w twoim pliku pnpm-lock.yaml. Jest problem dotyczący tego zagadnienia, który nadal jest otwarty w momencie pisania tego artykułu.
Instalacja najnowszej wersji bezpośredniej zależności, która ma docelową przechodnią zależność, może nie działać. Jeśli bezpośrednia zależność nie zaktualizowała definicji wersji, przechodnia zależność nie zostanie zaktualizowana, ponieważ została rozstrzygnięta i zablokowana w pliku pnpm-lock.yaml.
Pole overrides to potężna funkcja w PNPM, która pozwala zastąpić pewne rozstrzygnięcia wersji. Skorzystamy z tej funkcji, aby zaktualizować przechodnie zależności i dokonać minimalnych zmian.
Posłużmy się powyższym alertem Dependabot jako przykładem. Informuje nas on, że pakiet follow-redirects ma lukę w zabezpieczeniach, a naprawiona wersja to 1.15.6. Jednak bezpośrednia zależność gatsby używa axios, który zależy od [email protected].
Istnieje wiele sposobów na zlokalizowanie przechodniej zależności, ale polecam najprostszą metodę: wyszukanie pliku pnpm-lock.yaml.
A co z „pnpm why”?
Polecenie pnpm why <package> jest rzeczywiście przydatne. Jednakże w tym przypadku może Cię zmylić. Na przykład, kiedy uruchamiam pnpm why follow-redirects, oto część wyników:
W rzeczywistości w pliku pnpm-lock.yaml jest tylko jedno rozstrzygnięcie dla follow-redirects. Polecenie pnpm why może pokazać Ci wiele ścieżek zależności prowadzących do tej samej wersji pakietu.
Najłatwiejszy przypadek to taki, w którym istnieje tylko jedno rozstrzygnięcie w pliku pnpm-lock.yaml. Możesz bezpośrednio dodać zastąpienie do pliku package.json:
Jeśli jesteś w przestrzeni roboczej, powinieneś dodać zastąpienie do pliku package.json w głównym katalogu przestrzeni roboczej.
Uruchom polecenie pnpm install, aby zastosować zmiany. Możemy zobaczyć, że pakiet follow-redirects został zaktualizowany do 1.15.6 w pliku pnpm-lock.yaml przy minimalnych zmianach.
Teraz możesz usunąć pole overrides z pliku package.json, aby zachować go w czystości. Następnie uruchom ponownie pnpm install, aby zweryfikować, czy zmiany mogą zostać zastosowane bez pola overrides.
Powyższe kroki to idealny scenariusz. Rzeczy mogą nie zawsze iść zgodnie z oczekiwaniami. Oto kilka wskazówek dotyczących rozwiązywania problemów:
Wersja została przywrócona po usunięciu pola "overrides"#
Może się to zdarzyć, gdy pakiet zależny ma ustaloną wersję lub zakres, który nie obejmuje docelowej wersji. Sprawdź plik package.json pakietu zależnego, w tym przypadku axios, aby zobaczyć, czy to ma zastosowanie.
Jeśli tak, musisz zachować pole overrides w pliku package.json do czasu, aż pakiet zależny zaktualizuje definicje wersji.
Istnieje wiele rozstrzygnięć dla przechodniej zależności#
W miarę, jak projekt rośnie, plik pnpm-lock.yaml może zawierać wiele rozstrzygnięć dla tego samego pakietu. Na przykład mogą istnieć dwie główne wersje tego samego pakietu foo:
Raport o błędach bezpieczeństwa pokazuje, że [email protected] ma problem z bezpieczeństwem, który został naprawiony w 1.0.1, a [email protected] nie jest dotknięty. Nie możemy po prostu dodać zastąpienia dla foo:
Jeśli dodamy zastąpienie "foo": "^1.0.1", [email protected] zostanie zdegradowany do 1.0.1. Może to zniszczyć projekt, ponieważ [email protected] może mieć nowe funkcje, które są używane w pakietach zależnych.
Jeśli dodamy zastąpienie "foo": "^2.0.0", [email protected] zostanie zaktualizowany do 2.0.0. Może to zniszczyć projekt, ponieważ [email protected] może wprowadzać zmiany łamiące wsteczną kompatybilność.
Zakładając, że foo stosuje Semantyczne Wersjonowanie, możemy dodać zastąpienie w następujący sposób:
Zanim PNPM będzie wspierać bezpośrednie aktualizowanie przechodnich zależności, pole overrides jest dobrym obejściem, aby naprawiać luki w zabezpieczeniach bez psucia rzeczy. Mam nadzieję, że ten artykuł pomoże Ci radzić sobie z tymi sytuacjami bardziej efektywnie. W Logto używamy tej metody, aby nasze zależności były bieżące i bezpieczne.
