Ulepsz przechodnie zależności za pomocą PNPM: Napraw luki w zabezpieczeniach bez psucia rzeczy

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.

Metody, które nie działają#

• 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.

Rozwiązanie#

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].

Krok 1: Znajdź przechodnią zależność#

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.

Krok 2: Dodaj zastąpienia#

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.

Krok 3: Zastosuj zmiany#

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.

Rozwiązywanie problemów#

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:

To zaktualizuje tylko [email protected] do 1.0.1 i pozostawi [email protected] bez zmian.

Podsumowanie#

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.