Säkerhetspolicy

Herkos hanterar privata nycklar och krypterade meddelanden, så vi tar säkerhetsrapporter på allvar och hör hellre om ett problem tidigt än sent.

Rapportera en sårbarhet

Öppna inte ett offentligt ärende (issue) för säkerhetsproblem.

Rapportera det privat via GitHubs privata sårbarhetsrapportering, eller via e-post till security@herkos.email.

Bra att ta med: vad problemet är, hur det kan återskapas, vilken plattform och version du testade och vad en angripare skulle kunna uppnå. Ett konceptbevis (proof of concept) hjälper mycket.

Ta aldrig med din egen nsec, hemliga nyckel eller bunker-hemlighet i en rapport.

Vi försöker bekräfta rapporter inom några dagar. Eftersom Herkos är ett litet projekt ber vi dig ge oss rimlig tid för en åtgärd innan du offentliggör något. Vi nämner dig gärna i säkerhetsmeddelandet, om du inte föredrar något annat.

Vad som omfattas

Själva Herkos-appen: hantering och lagring av nycklar, kryptering och dekryptering av meddelanden (inklusive NIP-59-kontrollerna av avsändaren och isoleringen av Bcc i local_packages/nostr_mail), applåset, kommunikationen med reläer och bryggor, hanteringen av bilagor samt bygg- och releaseprocessen.

Vad som inte omfattas

Nostr-protokollet och dess NIP:ar i sig — rapportera sådant uppströms.
Reläer, bryggor och Blossom-servrar som drivs av tredje part. Herkos levereras med standardinställningar men driver dem inte; rapportera problem till deras operatörer.
Uppströmsprojektet Nostr Mail Client, om inte problemet gäller ändringar som gjorts i Herkos.
Saknad härdning som vi redan dokumenterar som en känd begränsning (se nedan).

Kända begränsningar, rakt på sak

Det här är avvägningar i designen, inte sårbarheter. Vi skriver hellre ut dem än låter någon upptäcka dem den hårda vägen:

Post till traditionella adresser är inte end-to-end-krypterad. Meddelanden mellan Nostr-användare använder NIP-17 gift wrap och är E2E-krypterade. När du skriver till en vanlig e-postadress konverterar en brygga meddelandet och kan läsa det.
Applåset (PIN-kod och biometri) är en bekvämlighetsspärr, inte kryptering av lagrade data. Det stoppar någon som plockar upp en olåst enhet; det skyddar inte mot en angripare med full åtkomst till enheten eller dess lagring.
På Windows går det inte att kräva enbart biometrisk autentisering. Windows Hello låter inte appen välja metod, så systemets PIN-kod finns alltid kvar som reserv.
Förlorar du din nyckel förlorar du kontot. Det finns ingen återställning, och det är avsiktligt.
Metadata döljs inte helt. Reläer kan observera anslutningsmönster, och varje relä ser din IP-adress, även när det inte kan läsa innehållet i meddelandena. Det Herkos inte avslöjar (sedan 2026-09-30) är vem som skriver till vem när ett relä begär NIP-42-autentisering:
Ta reda på vart posten ska levereras. En mottagares relä- och Blossom-listor hämtas över en separat anslutning som aldrig identifierar dig, i första hand från reläer som inte kräver autentisering (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Profiler och schemaläggaren. Namnet och bilden som visas för alla andra (kind 0), och schemaläggnings-DVM:ens relälista när du schemalägger eller avbryter ett mejl, hämtas på samma sätt: anonymt i första hand och, om ett relä insisterar, med den tillfälliga nyckel som beskrivs nedan, aldrig med din (sedan 2026-10-01; tidigare fick ett relä som begärde autentisering din nyckel och kunde se vems profil du tittade på). Bara din egen profil läses fortfarande som du.
Leverans. Gift wraps skickas till mottagarens DM-reläer, över samma separata anslutning. Om något av dem kräver autentisering svarar Herkos med en nyckel som skapats för ändamålet och bara finns i minnet, aldrig med din; varje konto på enheten har sin egen. Reläet kan fortfarande se att samma enhet (samma IP-adress, samma tillfälliga nyckel) skickade flera kuvert under en session.
Stora mejl. Den krypterade kopian av ett mejl på över 32 KB laddas upp till Blossom-servrar, även mottagarnas. Bara dina egna servrar (din Blossom-lista) får uppladdningen auktoriserad med din nyckel. Alla andra servrar får den anonymt och, om de insisterar på en auktorisering, en som signerats med samma tillfälliga nyckel som ovan (sedan 2026-10-01; tidigare fick varje server din nyckel). En server som bara godtar kända nycklar avvisar den, och kopian finns kvar på de andra servrarna.
Dina egna data. Synkronisering av din brevlåda, dina etiketter, inställningar och utkast autentiseras, där ett relä begär det, som det konto som uppgifterna tillhör, även när du byter konto. På dina egna reläer avslöjar det inget de inte redan visste: förfrågningarna namnger ändå din nyckel. Dina egna relä- och Blossom-listor är offentliga och hämtas utan att identifiera dig, och detsamma gäller reläer som anges i en e-postlänk.
Lässtatus och mappar är offentliga metadata (tills vidare). När du markerar ett mejl som läst, stjärnmärker, arkiverar eller flyttar det publiceras en okrypterad NIP-32-etiketthändelse kopplad till din offentliga nyckel, inklusive namnen på egna mappar. En avsändare som känner till id:t för ett mejl hen skickade till dig kan se när du gjorde något med det. Kryptering av dessa etiketter är planerad; tills dess bör du se mappnamn som offentliga.
Push-aviseringar och schemalagda utskick använder tjänster från tredje part. Push-servern (api.nmail.li som standard) får veta din offentliga nyckel, en push-token och när du tar emot post; schemaläggnings-DVM:en får veta din offentliga nyckel och de redan krypterade meddelanden den ska publicera. Båda är frivilliga och dokumenterade i PRIVACY.md. Texten i en push-avisering väljs av push-servern, och Herkos litar bara på den när UnifiedPush levererar den krypterad (RFC 8291); en okrypterad nyttolast väcker bara appen så att den själv hämtar posten.
Webbversionen förvarar din nyckel i webbläsaren, som är det svagaste stället för den. De installerade apparna lämnar din hemliga nyckel till operativsystemets säkra lagring (Android Keystore, Windows Autentiseringshanteraren, libsecret, iOS/macOS-nyckelringen). En webbläsare har inget av det: nyckeln ligger i ursprungets lagring och passerar genom JavaScript vid varje signatur, inom räckhåll för all kod som körs på sidan — ett webbläsartillägg med åtkomst till alla webbplatser, en XSS-bugg i appen eller i ett beroende, en manipulerad driftsättning — och för varje informationsstöldprogram (infostealer) som kopierar webbläsarprofilen. Det finns inte heller något tillfälle då du verifierar koden en gång för alla: en signerad binärfil kontrolleras vid installationen, medan en webbsida levererar ny kod vid varje besök. Logga in i webbversionen med en fjärrsignerare (NIP-46-bunker, Amber), så att nyckeln aldrig når webbläsaren, eller behandla den som en engångsidentitet och behåll din riktiga nyckel i en installerad app.
Post via brygga är bara så pålitlig som bryggan. Herkos verifierar att ett meddelande som är märkt som att det kommer via en brygga verkligen har signerats av en brygga du har konfigurerat (eller en av standardbryggorna). Appen kan inte verifiera något om den traditionella From:-adress som bryggan vidarebefordrar.
Bilagor öppnas av operativsystemet. Herkos startar aldrig körbara filer eller skriptfiler och frågar innan någon annan bilaga som inte kan förhandsgranskas lämnas till systemets standardapp, men appen som öppnar filen ligger utanför vår kontroll.

Versioner som stöds

Säkerhetsrättelser görs i den senast släppta versionen. Med tanke på projektets storlek underhålls inte äldre versioner — uppdatera innan du rapporterar.