Obsidian 1.9.13 (wczesny dostęp) jest teraz dostępny dla członków Catalyst na komputery stacjonarne i urządzenia mobilne z poprawkami błędów i ulepszeniami wydajności.

Mniej znaczy bezpieczniej: jak Obsidian zmniejsza ryzyko ataków na łańcuch dostaw Ataki na łańcuch dostaw to złośliwe aktualizacje, które wkradają się do kodu open source używanego przez wiele aplikacji. Oto jak projektujemy Obsidian, aby zapewnić, że aplikacja jest bezpiecznym i prywatnym środowiskiem dla Twoich myśli. Mniej znaczy bezpieczniej Może to brzmieć oczywiście, ale podstawowym sposobem, w jaki zmniejszamy ryzyko ataków na łańcuch dostaw, jest unikanie polegania na kodzie osób trzecich. Obsidian ma niewielką liczbę zależności w porównaniu do innych aplikacji w naszej kategorii. Zobacz listę bibliotek open source na naszej stronie z uznaniami. Funkcje takie jak Bases i Canvas zostały zaimplementowane od podstaw, zamiast importować gotowe biblioteki. Daje nam to pełną kontrolę nad tym, co działa w Obsidian. - W przypadku małych funkcji użytkowych prawie zawsze ponownie je implementujemy w naszym kodzie. - W przypadku średnich modułów fork'ujemy je i trzymamy w naszym kodzie, jeśli licencje na to pozwalają. - W przypadku dużych bibliotek, takich jak pdf.js, Mermaid i MathJax, dołączamy znane, zablokowane wersje plików i aktualizujemy je tylko okazjonalnie lub gdy pojawiają się poprawki bezpieczeństwa. Czytamy notatki o wydaniach, przyglądamy się zmianom upstream i dokładnie testujemy przed przełączeniem. Takie podejście utrzymuje naszą grafikę zależności płytką z niewielką liczbą podzależności. Mniejsza powierzchnia zmniejsza szansę na to, że złośliwa aktualizacja przejdzie niezauważona. Co właściwie znajduje się w aplikacji Tylko garstka pakietów jest częścią aplikacji, którą uruchamiasz, np. Electron, CodeMirror, moment.js. Pozostałe pakiety pomagają nam w budowie aplikacji i nigdy nie trafiają do użytkowników, np. esbuild czy eslint. Zablokowane wersje i pliki blokady Wszystkie zależności są ściśle zablokowane pod względem wersji i zatwierdzone z plikiem blokady. Plik blokady jest źródłem prawdy dla budów, więc uzyskujemy deterministyczne instalacje. Daje nam to prosty ślad audytowy podczas przeglądania zmian. Nie uruchamiamy skryptów postinstall. Zapobiega to wykonywaniu dowolnego kodu przez pakiety podczas instalacji. Powolne, przemyślane aktualizacje Kiedy aktualizujemy zależności,: 1. Czytamy changelog zależności linia po linii. 2. Sprawdzamy podzależności wprowadzone przez nową wersję. 3. Porównujemy zmiany upstream, gdy zestaw zmian jest duży lub ryzykowny. 4. Uruchamiamy testy automatyczne i manualne na różnych platformach i krytycznych ścieżkach użytkowników. 5. Zatwierdzamy nowy plik blokady dopiero po pomyślnym przejściu tych przeglądów. W praktyce rzadko aktualizujemy zależności, ponieważ zazwyczaj działają i nie wymagają częstych zmian. Kiedy to robimy, traktujemy każdą zmianę tak, jakbyśmy przyjmowali nową zależność. Czas to bufor Nie spieszymy się z aktualizacjami. Istnieje opóźnienie między aktualizacją jakiejkolwiek zależności a wydaniem. Ta luka działa jako okno wczesnego ostrzegania: społeczność i badacze bezpieczeństwa często szybko wykrywają złośliwe wersje. W momencie, gdy jesteśmy gotowi do wydania, ekosystem zazwyczaj oznaczył wszelkie problematyczne wydania. — Żadne pojedyncze działanie nie może wyeliminować ryzyka związanego z łańcuchem dostaw. Ale wybierając mniej zależności, płytkie grafy, dokładne zablokowane wersje, brak postinstall oraz powolny, oparty na przeglądach cykl aktualizacji, sprawiamy, że Obsidian jest znacznie mniej narażony na wpływ i daje nam długi czas na wykrycie problemów, zanim kod dotrze do użytkowników. Jeśli jesteś ciekawy naszego szerszego podejścia do bezpieczeństwa, zobacz naszą stronę o bezpieczeństwie i wcześniejsze audyty.

Nagroda zwiększona do 5 000 $