Polityka bezpieczeństwa

Herkos przetwarza klucze prywatne i zaszyfrowane wiadomości, dlatego poważnie traktujemy zgłoszenia dotyczące bezpieczeństwa i wolimy dowiedzieć się o problemie wcześniej niż później.

Zgłaszanie podatności

Prosimy nie otwierać publicznego zgłoszenia (issue) w sprawie problemów z bezpieczeństwem.

Zgłoś je prywatnie przez prywatne zgłaszanie podatności w GitHubie albo e-mailem na security@herkos.email.

Warto podać: na czym polega problem, jak go odtworzyć, na jakiej platformie i wersji go testowałeś oraz co mógłby osiągnąć atakujący. Dowód koncepcji (proof of concept) bardzo pomaga.

Nigdy nie umieszczaj w zgłoszeniu swojego nsec, klucza prywatnego ani sekretu bunkra.

Staramy się potwierdzać zgłoszenia w ciągu kilku dni. Ponieważ Herkos jest małym projektem, daj nam rozsądny czas na poprawkę przed publicznym ujawnieniem. Chętnie wymienimy Cię w komunikacie bezpieczeństwa, chyba że wolisz inaczej.

Co obejmuje ta polityka

Samą aplikację Herkos: obsługę i przechowywanie kluczy, szyfrowanie i odszyfrowywanie wiadomości (w tym weryfikację nadawcy NIP-59 i izolację Bcc w local_packages/nostr_mail), blokadę aplikacji, komunikację z przekaźnikami i bridge'ami, obsługę załączników oraz proces budowania i wydawania.

Czego nie obejmuje

• Samego protokołu Nostr i jego NIP-ów — zgłaszaj to ich twórcom.
• Przekaźników, bridge'y i serwerów Blossom prowadzonych przez osoby trzecie. Herkos ma je w ustawieniach domyślnych, ale ich nie prowadzi; zgłaszaj problemy ich operatorom.
• Projektu macierzystego Nostr Mail Client, chyba że problem dotyczy zmian wprowadzonych w Herkos.
• Brakujących zabezpieczeń, które już dokumentujemy jako znane ograniczenie (zob. niżej).

Znane ograniczenia, powiedziane wprost

To kompromisy projektowe, a nie podatności. Wolimy je zapisać, niż żeby ktoś odkrył je w bolesny sposób:

• Poczta na tradycyjne adresy nie jest szyfrowana end-to-end. Wiadomości między użytkownikami Nostr używają gift wrap NIP-17 i są szyfrowane E2E. Gdy piszesz na zwykły adres e-mail, bridge konwertuje wiadomość i może ją przeczytać.
• Blokada aplikacji (PIN i biometria) to bariera wygody, a nie szyfrowanie danych w spoczynku. Zatrzymuje kogoś, kto podniesie odblokowane urządzenie; nie chroni przed atakującym z pełnym dostępem do urządzenia lub jego pamięci.
• W systemie Windows nie da się wymusić uwierzytelniania wyłącznie biometrią. Windows Hello nie pozwala wybrać metody, więc systemowy PIN zawsze pozostaje dostępny jako rozwiązanie zapasowe.
• Utrata klucza oznacza utratę konta. Z założenia nie ma odzyskiwania.
• Metadane nie są w pełni ukryte. Przekaźniki mogą obserwować wzorce połączeń, a każdy przekaźnik widzi Twój adres IP, nawet gdy nie może odczytać treści wiadomości. Czego Herkos nie zdradza (od 30-09-2026), to kto pisze do kogo, gdy przekaźnik żąda uwierzytelnienia NIP-42:
• Ustalanie, gdzie doręczyć. O listy przekaźników i serwerów Blossom odbiorcy pytamy przez osobne połączenie, które nigdy Cię nie identyfikuje, najpierw na przekaźnikach niewymagających uwierzytelnienia (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Profile i harmonogram. O nazwę i zdjęcie wyświetlane dla innych osób (kind 0) oraz o listę przekaźników DVM harmonogramu, gdy planujesz lub anulujesz e-mail, pytamy w ten sam sposób: najpierw anonimowo, a jeśli przekaźnik nalega, z tymczasowym kluczem opisanym niżej, nigdy z Twoim (od 01-10-2026; wcześniej przekaźnik żądający uwierzytelnienia dostawał Twój klucz i mógł stwierdzić, czyj profil oglądasz). Tylko Twój własny profil jest nadal odczytywany jako Ty.
• Doręczanie. Gift wrapy trafiają do przekaźników DM odbiorcy, przez to samo osobne połączenie. Jeśli któryś z nich wymaga uwierzytelnienia, Herkos odpowiada kluczem utworzonym w tym celu i przechowywanym wyłącznie w pamięci, nigdy Twoim; każde konto na urządzeniu ma własny. Przekaźnik nadal może zobaczyć, że to samo urządzenie (ten sam IP, ten sam tymczasowy klucz) wysłało kilka kopert w trakcie sesji.
• Duże e-maile. Zaszyfrowana kopia e-maila większego niż 32 KB jest przesyłana na serwery Blossom, także odbiorców. Tylko Twoje własne serwery (Twoja lista Blossom) otrzymują przesyłanie autoryzowane Twoim kluczem. Każdy inny serwer otrzymuje je anonimowo, a jeśli nalega na autoryzację — podpisaną tym samym tymczasowym kluczem co wyżej (od 01-10-2026; wcześniej każdy serwer dostawał Twój klucz). Serwer, który przyjmuje tylko znane klucze, odmawia, a kopia zostaje na pozostałych serwerach.
• Twoje własne dane. Synchronizacja skrzynki, etykiet, ustawień i wersji roboczych uwierzytelnia się, gdy przekaźnik tego żąda, jako konto, do którego dane należą, nawet podczas przełączania kont. Twoim własnym przekaźnikom nie mówi to nic, czego by nie wiedziały: żądania i tak zawierają Twój klucz. Twoje własne listy przekaźników i serwerów Blossom są publiczne i pobierane bez identyfikowania Cię, podobnie jak przekaźniki wskazane w linku w e-mailu.
• Stan przeczytania i foldery są publicznymi metadanymi (na razie). Oznaczenie e-maila jako przeczytanego, z gwiazdką, zarchiwizowanego lub przeniesionego publikuje niezaszyfrowane zdarzenie etykiety NIP-32 powiązane z Twoim kluczem publicznym, łącznie z nazwami folderów własnych. Nadawca, który zna identyfikator wysłanego Ci e-maila, może stwierdzić, kiedy coś z nim zrobiłeś. Szyfrowanie tych etykiet jest planowane; do tego czasu traktuj nazwy folderów jako publiczne.
• Powiadomienia push i wysyłanie zaplanowane korzystają z usług osób trzecich. Serwer push (domyślnie api.nmail.li) poznaje Twój klucz publiczny, token push i to, kiedy otrzymujesz pocztę; DVM harmonogramu poznaje Twój klucz publiczny i już zaszyfrowane wiadomości, które ma opublikować. Obie funkcje są opcjonalne i opisane w PRIVACY.md. Tekst powiadomienia push wybiera serwer push, a Herkos ufa mu tylko wtedy, gdy UnifiedPush dostarcza go zaszyfrowanego (RFC 8291); niezaszyfrowany ładunek jedynie budzi aplikację, aby sama pobrała pocztę.
• Wersja webowa przechowuje Twój klucz w przeglądarce, która jest dla niego najsłabszym miejscem. Zainstalowane aplikacje przekazują Twój klucz prywatny do bezpiecznego magazynu systemu operacyjnego (Android Keystore, Menedżer poświadczeń Windows, libsecret, pęk kluczy iOS/macOS). Przeglądarka nie ma nic takiego: klucz leży w magazynie danego pochodzenia (origin) i przy każdym podpisie przechodzi przez JavaScript, w zasięgu każdego kodu działającego na stronie — rozszerzenia przeglądarki z dostępem do wszystkich stron, błędu XSS w aplikacji lub w zależności, zmanipulowanego wdrożenia — oraz każdego infostealera, który kopiuje profil przeglądarki. Nie ma też momentu, w którym weryfikujesz kod raz: podpisany plik binarny jest sprawdzany przy instalacji, a strona internetowa przy każdej wizycie dostarcza nowy kod. Loguj się do wersji webowej zdalnym podpisującym (bunkier NIP-46, Amber), aby klucz nigdy nie trafił do przeglądarki, albo traktuj ją jako tożsamość jednorazową, a swój prawdziwy klucz trzymaj w zainstalowanej aplikacji.
• Poczta przez bridge jest tak wiarygodna jak sam bridge. Herkos sprawdza, czy wiadomość oznaczona jako przechodząca przez bridge rzeczywiście została podpisana przez skonfigurowany przez Ciebie bridge (lub jeden z domyślnych). Nie może zweryfikować niczego w tradycyjnym adresie From:, który bridge przekazuje.
• Załączniki otwiera system operacyjny. Herkos nigdy nie uruchamia plików wykonywalnych ani skryptów i pyta, zanim przekaże każdy inny załącznik bez podglądu do domyślnej aplikacji systemu, ale aplikacja, która otwiera plik, jest poza naszą kontrolą.

Wspierane wersje

Poprawki bezpieczeństwa trafiają do najnowszej wydanej wersji. Ze względu na rozmiar projektu starsze wersje nie są utrzymywane — przed zgłoszeniem zaktualizuj aplikację.