urMQTT po VPS: SQLite v používateľskom režime, porovnanie s Mosquittom, konfigurácia ako dáta a zostavovač v prehliadači

Druhý text, urMQTT na skutočnom VPS, skončil zoznamom „Čo bude ďalej": H6 (SQLite mimo jadra), H7 (bezpečnosť času), X11 (porovnanie s Mosquittom na tom istom VPS) a prvé vydanie. Tento text sleduje ten zoznam v rovnakom poradí a potom pridáva dve veci, ktoré na zozname neboli, lebo sa objavili popri práci: konfiguráciu ako dáta s webovým zostavovačom ISO a voliteľný obyčajný MQTT bez TLS. Ako predtým: čo sme plánovali, čo sme postavili, čo nás prekvapilo a čo je otvorené. V tomto texte je aj niekoľko výsledkov, ktoré nejdú v prospech urMQTT; nechali sme ich, lebo sú súčasťou pravdy.

Poznámka vopred ostáva rovnaká: projekt je pred-alfa, prvé vydanie je len pre VPS s KVM a čísla merajú kód, testy a určité pokusy, nie zrelosť v produkcii.

Ako to vyzeralo v čase

Od predchádzajúceho textu (31.10. o 23:00) do dnes (1.11. o 20:41) pribudlo v repozitári 59 nových commitov, spolu 178. Všetky vznikli v jednom kalendárnom dni, takže platí rovnaké upozornenie ako predtým: projekt sa buduje s Claude Code (commity nesú Co-Authored-By: Claude), plán, kód, testy a ADR vznikajú v krátkych uzavretých slučkách a čísla nižšie hovoria o množstve kódu a overovaní, nie o tom, koľko ľudskej práce v nich je.

Čísla sú vypočítané rovnakou metódou ako v minulom texte: všetky súbory .rs mimo vendor/ a fuzz/, funkcie #[test], nadpisy ## ADR- v docs/DECISIONS.md.

Okamih	Commit	Čas	Riadkov Rustu	Testov	ADR
minulý text	794f607	31.10. 23:00	89 790	739	104
H6 hotový	a0423cc	1.11. 03:59	95 078	754	107
X11	a29f49b	1.11. 07:56	95 579	754	108
webový zostavovač a zrkadlo vydaní	582783f	1.11. 16:49	105 645	848	122
obyčajný MQTT, dokumentácia	8f959f1	1.11. 19:05	112 408	926	125
dnes	d21e3ec	1.11. 20:41	112 408	926	126

Pracovalo sa paralelne na viacerých vetvách, takže poradie commitov nie je presne poradím práce. ADR sú číslované až do 232, ale číslovanie má medzery (časť sa pri zlučovaní vetiev premenovala); počítame nadpisy, nie najvyššie číslo. Vydania: v0.2.0 (1.11., 18:45 UTC) a v0.2.1 (1.11., 20:22 UTC), obe označené ako pre-release.

H6: SQLite v používateľskom režime

Čo sme plánovali. SQLite je 254 268 riadkov C, ktoré parsujú databázu, WAL a žurnál z disku, a disk môže byť vyrobený alebo zmenený. Dovtedy bežal v jadre, s právami jadra. Čo sme postavili (ADR-210 až ADR-212): SQLite, jeho časti libc a heap sa presunuli do samostatného programu, dbworker, ktorý beží na EL0 (aarch64), resp. ring 3 (x86_64), vo vlastnom adresnom priestore. Jadro už SQLite nelinkuje. Worker komunikuje s jadrom cez spoločné okno pamäte a dvanásť systémových volaní a každá dĺžka a posun, ktoré sa vrátia, sa pred použitím kontrolujú. Chyba vo workeri (nepovolený prístup, nedefinovaná inštrukcia, prekročený časový rozpočet 30 s) ukončí volanie, worker sa znova spustí a databáza sa otvorí z WAL ako pri zavádzaní; po 5 opätovných spusteniach za minútu sa úložisko vyhlási za chybné a nespúšťa sa donekonečna.

Cena, nameraná na aarch64 pod HVF, tá istá VM, jadro so zabudovaným SQLite oproti jadru s workerom, šesť striedavých spustení každého:

Meranie	Predtým (v jadre)	Potom (worker)	Rozdiel
vstup do používateľského režimu a výstup z neho	-	1,1 us na kolo
db-bench, 5 000 vložení v 50 transakciách, najlepší / medián	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6% / -8,7%
jedno vloženie na transakciu, najlepší / medián	2 319 / 2 148 op/s	2 307 / 2 126 op/s	-0,5% / -1%
celá záloha jedným volaním (23 MiB)	514 ms	635 ms	+23%

Zápisy na disk (1 572) a flushe (319) sú identické, ako to má byť. Toto nie je izolované: jadro stále verí tomu, čo worker vráti, po kontrole tvaru. Kompromitovaný worker môže klamať (napríklad vrátiť prázdny zoznam zrušených certifikátov a tým ich „odrušiť"), ale nemôže čítať pamäť jadra, kľúče TLS ani kľúče tiketov. Nie je tu KPTI, takže úniky typu Spectre/Meltdown nie sú zabránené a nič o nich netvrdíme; kľúč PAC zdieľajú EL0 a EL1. Na x86_64 sme cenu prepínania na KVM nemerali (pod TCG by bolo číslo nezmyselné) a samotné fuzzovanie workera a protokolu nie je hotové. Súbor testov pre úložisko (79 scenárov, každý točí SQLite vo workeri) prechádza na aarch64 HVF a x86_64 TCG, na aarch64 TCG 76 (jeden sa preskakuje, lebo TCG nemá MSI-X).

H7 je uzavretý, ale nie tak, ako sme ohlásili. Dolná hranica času (ADR-050) a SNTP s konsenzom (T1) pokrývajú rozsah H7; NTS (RFC 8915) ostáva mimo rozsahu a je zapísaný ako zvyškové riziko, nie ako niečo, čo funguje. Nepovažujeme bezpečnosť času za „vyriešenú", ale za hotovú v jej dokázateľnej časti.

Nová sieťová možnosť. Contabo nedáva DHCP vlastnému ISO, takže VPS dovtedy potreboval iný obraz než laboratórna VM. Teraz network.mode = "auto" (ADR-214) najprv sa opýta DHCP a ak prenájom nepríde v danej lehote (dhcp_timeout_s, predvolene 15 s) alebo ho stratí, použije zadanú statickú adresu. Vyskúšané ručne na QEMU (s DHCP použije prenájom, bez siete sa po 5 s vráti na statickú adresu); smoke scenár na to ešte nie je.

X11: porovnanie s Mosquittom na tom istom VPS

Rovnaký druh stroja ako v minulom texte (Contabo, 4 vCPU AMD EPYC, 8 GiB), záťaž z linuxového hostiteľa vzdialeného 15 ms, vzájomné TLS 1.3 s rovnakými certifikátmi na oboch stranách, Mosquitto 2.0.21 na Debiane 13 bez trvanlivosti. Metóda a rozhodnutia sú v ADR-213, surové dáta v docs/perf-results/. Medián z troch spustení.

	urMQTT	Mosquitto 2.0.21
podania rúk/s, 32 / 64 / 128 klientov (bench profil)	169 / 278 / 413	82 / 140 / 184
to isté, s limitmi, aké sa dodávajú	185 / 262 / 333 (pri 128: 202 až 286 chýb, reset podania rúk)	-
pamäť na neaktívne spojenie (20 000 spojení)	0,50 KB haldy jadra (0,66 KB pri 5 000)	26,8 KB rastu procesu
latencia p50, QoS 0 / QoS 1, 800 správ/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4 800 správ/s, doručené/s (p50)	4 209 (77 ms)	4 235 (197 ms)
100 odberateľov, 50 správ/s: p50	16,6 ms	99 ms
jeden tok, QoS 0, 64 B, publikované/s	2 962 (0 až 7 733)	22 749

Čo to znamená a čo nie. Podania rúk sú dolné hranice pre oba servery: generátor záťaže je zdieľaná VM s 60 až 70% ukradnutého procesorového času a pri 128 vláknach bol blízko vlastného limitu, kým pracovné jadrá urMQTT boli zaneprázdnené iba 12 až 13%. Pomer pri 128 klientoch (približne 2,2-krát) je najzmysluplnejší; pri 32 a 64 väčšinou meria čakanie klientov. Čísla pamäte nepočítajú to isté (halda jadra oproti RSS procesu), takže „približne 50-krát menej" je rádovo, nie presný pomer. Latencia 14 ms je jedno kolo siete (približne 15 ms), teda „žiadny merateľný čas brokera"; chvosty (p99 približne 100 až 200 ms) sú pri oboch brokeroch ovládané zdieľanými hostiteľmi. Rozdiely pod približne 20% netvrdíme.

Čo nešlo v náš prospech a zostalo v tabuľkách: jeden TCP tok cez urMQTT niesol 2 až 8-krát menej než cez Mosquitto, so zmenami od nuly do 7,7 tisíc správ za sekundu medzi spusteniami, a 20 ms watchdog handlera prerušoval živé spojenia, keď hypervízor zastavil vCPU (v produkčnom nastavení action = "drop", 6 až 8 spojení na spustenie pri zaplavení QoS 0). Obe veci sú opísané v ďalšej časti, lebo mali príčiny v našom kóde.

Prečo bol jeden tok pomalý: príčiny, nie výhovorky

Najjednoduchšie by bolo povedať „zdieľaný VPS". Nepovedali sme to, ale pri tom istom VPS a tej istej metóde sme hľadali príčiny. Našlo sa ich päť, štyri v dátovej ceste a jedna vo watchdogu (ADR-221 až ADR-224):

Príznak v X11	Príčina v urMQTT	Zmena
jeden tok 1,9k správ/s, často 0 doručených	Stratené prebudenie: výstupná slučka vracala zoznam pripravených spojení cez práve vypísaný; odberateľ, ktorému sa raz zaplnil výstupný medzipamäť, už nebol nikdy obslúžený, kým ho neprebudil PINGRESP	opravené (ADR-223)
niekoľko percent straty mení 48k na 14k správ/s	každý segment po stratenom bol zahodený (príjem iba v poradí), takže obnova stála kolo siete na segment	rad segmentov mimo poradia, SACK (ADR-222)
strop 4,4 MB/s pri 15 ms	16-bitové okno, rad odosielania 64 KiB a pomalý štart, ktorý počítal ACK, nie bajty	škálovanie okna, časové značky, počítanie bajtov (ADR-222)
každé kolo toku, ktoré sa zmestí, čaká 0 až 10 ms	dispečer spal do ďalšieho tiku 10 ms (virtio-net nemá prerušenie pre príjem)	dopytovanie NIC každých 200 us, kým existujú spojenia (ADR-224)
1 až 8 prerušených spojení na spustenie	watchdog handleru účtoval uplynulý čas, a VPS zastavuje vCPU často a dlho	rozpočet je čas, ktorý jadro skutočne bežalo (ADR-221)

Zastavenia sú skutočné: na tomto VPS mali jadrá 0 až 2 medián 36 až 80 oneskorených tikov za 5 sekúnd a najhoršie zastavenie v okne bolo v mediáne približne 70 ms a až 0,9 s (jadro 3, databáza a žurnál: až 1,55 s), kým hostiteľ nehlási ukradnutý čas (host steal 0 us). Preto watchdog potreboval druhé hodiny, nie väčší rozpočet.

	kód X11 (7f9517e)	teraz (86a71ff)	Mosquitto
jeden tok, QoS 0, 64 B, publikované / doručené za s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
jeden tok, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 párov, zaplavenie, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 párov, zaplavenie, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
stratené spojenia na spustenie (16 párov, 64 B)	13 (7 až 16)	0 (0 až 0)	0

Watchdog: 148 prerušených spojení v 30 zaťažených spusteniach predtým, 0 v 24 spusteniach potom; na lokálnom zariadení, ktoré oneskoruje a stráca rámce, má pri strate 0,1% jeden tok 64 B s 14,3k správ/s (jadro X11) teraz 41,0k, a pri 0,5% 5,0k namiesto 17,7k.

Čo toto nehovorí. urMQTT stále nie je rýchlejší než Mosquitto na jednom toku: pri 64 B publikuje približne 80% jeho rýchlosti a doručuje približne 40%, lebo zahadzuje QoS 0, keď je tok odberateľa pomalší než tok vydavateľa (Mosquitto bez hranice zaraďuje do radu). Pri 1 KiB v 16-párovom zaplavení je Mosquitto popredu približne o 15%, čo je v rámci šumu. Generátor bol znova zdieľaná VM s 58 až 77% ukradnutého času. Druhé kolo (zamykanie haldy mimo dátovej cesty, SACK na strane odosielania a ďalšie) je na neintegrovanej vetve perf-single-flow-wip; jeho čísla zatiaľ nie sú tvrdenia a neuvádzame ich tu.

Sľub, ktorý sme nedali, ale splnili sme ho: konfigurácia je dáta

Doteraz bola každá konfigurácia novým zostavením: kľúče a limity boli zabudované v obraze. C1 to obracia (ADR-215 až ADR-219): jadro sa zostavuje raz a konfigurácia sú dáta.

• Blob urmqtt-cfg (C1a): verzovaný, kanonický zápis (polia podľa rastúcich značiek, odtlačok SHA-256, voliteľný oddelený podpis Ed25519), 70 polí s predvolenými hodnotami a hranicami, dekodér, ktorý odmieta všetko chybné.
• Jadro ho číta ako modul Limine (C1b), pred čímkoľvek iným, na aarch64 a x86_64. Existuje jedno vydané jadro pre každé ENV okrem dev (ELF-y aarch64 pre release, prod a bench majú rovnaké SHA-256; overené iba na aarch64). Vydané jadro odmieta vývojovú konfiguráciu a bez konfigurácie napíše „refusing to serve" a nič neposkytuje.
• Nainštalovaný disk nesie konfiguráciu a aktualizácia ju zachováva (C1c).
• urmqtt-config a šablóna ISO (C1d): pack, show, verify, a pack --iso nahrádza obe kópie miesta pre konfiguráciu a 24 súhrnov modulov v hotovom ISO. Výsledok je bajt po bajte rovnaký ako ISO, ktoré zostavuje mkiso.sh --config. Šablóna vydania v0.2.0 má 63 111 168 bajtov.
• Vyhlásenie o dôvere (ADR-219): nakonfigurovaný obraz pri zavádzaní vypíše odtlačok konfigurácie (config: fingerprint ...) a podpis je voliteľný a predvolene vypnutý. Zmenené ISO nemá oficiálny súhrn; odtlačok je spôsob, ako vidieť, čo je v ňom.

Zostavovač na aldo.tech

To isté, čo robí urmqtt-config pack --iso, robí aj webová stránka, tým istým kódom: knižnica nástroja preložená do WebAssembly (1,06 MB, bez importov a bez bloku unsafe). Stránka je na aldo.tech/sk/produkty/urmqtt-builder/ a existuje vo všetkých 15 jazykoch stránky (napríklad hr).

• Nič neopúšťa prehliadač. Certifikáty, súkromné kľúče a hotové ISO ostávajú v počítači; stránka sťahuje iba súbory vydania z tohto miesta, nie je tu sledovanie ani skripty tretích strán. V teste naživo žiadna požiadavka nenies kľúčový materiál.
• Zrkadlo vydaní (ADR-227): hodinu po hodine (systemd timer, nízka priorita) kopíruje vydania z GitHubu, každé skontroluje pred zverejnením a stránka v prehliadači overuje podpis SHA256SUMS kľúčom zabudovaným v stránke, a až potom zapíše konfiguráciu do šablóny. Neúspešná kontrola blokuje stiahnutie.
• Jednoducho podľa predvoleného, pokročilo podľa potreby (ADR-232): prvá obrazovka sú tri kroky (kde to pobeží, vaše certifikáty, názov obrazu). Jedno pole na pretiahnutie súborov roztriedi certifikát, kľúč a CA podľa obsahu. Pokročilé zobrazenie otvára každé zo 70 polí, vyhľadávanie, import a export TOML; obe zobrazenia upravujú rovnaký stav. Šablóna (63 MB) sa sťahuje, kým používateľ vypĺňa formulár. V skúške naživo, so skúšobným zrkadlom a skúšobným kľúčom, zostavenie ISO v prehliadači trvalo 5 až 18 s.

Emulátor, voliteľne. Vedľa „Stiahnuť ISO" stojí „Vyskúšať v emulátore": QEMU preložené do WebAssembly spustí práve zostavený obraz v karte prehliadača. Nič z neho sa nesťahuje pred kliknutím (približne 3 MB prvýkrát). Emulátor je len BIOS, bez siete (aby prevádzka používateľa neprešla cez nejakého sprostredkovateľa a nenarušila „nič neopúšťa prehliadač"), vyžaduje približne 1,5 GB pamäte a počítačový prehliadač (testovaný Chrome; Firefox a Safari nie). V ňom urMQTT dosiahne URMQTT READY približne za 8 s (s preskočeným odpočítavaním) a vypíše rovnaký odtlačok konfigurácie ako stránka, čo je dôkaz, že sa zaviedla práve tá konfigurácia. Zavedenie je približne 2-krát pomalšie než pôvodné QEMU na tom istom Macu (0,82 s oproti 1,9 s) a kryptografia približne 58-krát pomalšia, lebo hardvérové inštrukcie sú emulované. Preto z emulátora nevyvodzujeme žiadne tvrdenia o rýchlosti a stránka to hovorí pred spustením. Pri zostavení bolo treba záplatovať štyri bajty v .wasm kvôli chybe v preklade inštrukcie POPCNT v pôvodnom emulátore (ešte sme ju nenahlásili); samotný emulátor je pod GPL, s ponukou zdrojového kódu.

Obyčajný MQTT, len pre siete, ktorým dôverujete

Obyčajný MQTT (TCP 1883, bez TLS) je v IoT veľmi bežný: je predvolený v Mosquittu, vo väčšine firmvérov pre Arduino a ESP, v Tasmote, Zigbee2MQTT a Home Assistante a používa sa aj vo vnútri segmentovaných priemyselných sietí, za VPN a na súkromných LAN, ba aj na zariadeniach bez hodín (certifikáty vyžadujú dátum), bez dostatku flash pamäte alebo procesora pre TLS. Cez nespoľahlivú sieť neprichádza do úvahy: kto je na ceste, číta a mení prevádzku. Preto je P1 (ADR-229 až ADR-231) výslovná, obmedzená voľba, predvolene vypnutá, a port TLS ostáva; TLS sa tým nevypína, obyčajný port prichádza popri ňom.

• Zoznam povolených sietí je povinný (allow_from, CIDR) a kontroluje sa pri SYN: mimo zoznamu nie je SYN-ACK ani stav. Celý internet (0.0.0.0/0) vyžaduje samostatnú výslovnú možnosť.
• Tri spôsoby prihlásenia: heslo (predvolené, keď je zapnuté; PBKDF2-HMAC-SHA-256, soľ, 10 000 iterácií, porovnanie v konštantnom čase, zamykanie podľa adresy), anonymne (jedna nakonfigurovaná identita s vlastným ACL) a podľa adresy (ip). Zostavovač heslo rozptyľuje v prehliadači a v pamäti drží iba súhrn.
• Menej práv než mTLS: obyčajný klient nikdy nemá servisné, operátorské ani riadiace práva, nemá $SYS ani konzolu, má vlastné relácie ($plain/<identita>/<id klienta>, iba čisté), vlastné limity a register povolených ho stále zaväzuje.
• Čo sa stráca, je napísané v SECURITY.md: dôvernosť, integrita, autentickosť brokera a opakovanie zachyteného prihlásenia. To sa konfiguráciou nedá opraviť; tak to je bez TLS.

Namerané na laptope (Apple silicon, HVF, používateľská sieť QEMU), 16 párov, 64 B, tri spustenia po 10 s: pri 8 000 správach za sekundu TLS aj obyčajná cesta doručia všetky správy s rovnakou latenciou (p50 0,17 ms oproti 0,13 až 0,18 ms), nové spojenia za sekundu: TLS približne 2 600 až 2 750, anonymné obyčajné približne 4 900 až 7 800, a prihlásenie heslom je drahá časť: jeden PBKDF2 stojí približne 2,5 ms, takže počet nových prihlásení je obmedzený na približne 200 na dátové jadro za sekundu (namerané 308 až 342 na dvoch jadrách). Zaplavenie na tomto stroji nie je stabilný nástroj (20k až 440k doručených za sekundu medzi spusteniami) a z neho nevyvodzujeme záver. Porovnanie obyčajnej cesty s Mosquittom na VPS ešte nie je urobené. Testy: smoke skupina plaintext 7 zo 7 na aarch64 HVF a na x86_64 TCG, nový fuzz cieľ plain_input (2,3 milióna spustení bez nálezov).

Chyby, ktoré našla práca naživo

Dve veci neodchytili testy, ale prvé zapnutie na skutočnom mieste:

• Stránka hľadala súbory vydania o jeden adresár vyššie, takže každé overenie podpisu odpovedalo 404 (oprava 13af301). Test používal skúšobné zrkadlo na inej ceste.
• Klávesnica emulátora nikdy nedorazila k hosťovi: príčinou nebol zlý preklad kláves, ale to, že dialóg klávesy vôbec nepočúval (oprava v ADR-232, spolu so vstupom na zavedenie bez kláves).

Lekcie

• Hľadajte príčinu, neobviňujte prostredie. Väčšina slabín jedného toku a všetky prerušené spojenia boli naše; hypervízor je skutočný, ale bolo ho treba merať, nie predpokladať.
• Porovnanie s iným produktom musí zahŕňať aj straty. Tabuľka, v ktorej sú iba naše víťazstvá, by nebola porovnaním.
• Merací prístroj má hranice. Zdieľaný generátor so 60 až 70% ukradnutého času mení, čo čísla znamenajú; preto píšeme „dolná hranica" a netvrdíme rozdiely pod 20%.
• Izolácia nie je dôkaz. SQLite v EL0 zmenšuje, čo môže chyba v ňom, nie to, čo môže klamať.
• Skutočná inštalácia nájde to, čo testy nehľadajú: cestu, ktorá bola nesprávne poskladaná, a klávesy, ktoré nikto nepočúva.

Čo ešte nie je dokázané

• Podpisový kľúč vydaní je zatiaľ skúšobný kľúč; v0.2.0 a v0.2.1 sú pre-release a obrazy k nim sú vývojové so skúšobnými certifikátmi (okrem šablóny, ktorá je bez konfigurácie).
• 13 prekladov stránky zostavovača (a tohto textu) napísala AI a overili ich testy a vzorky, nie rodení hovoriaci.
• Porovnanie s Mosquittom je jedna relácia, jedna cesta a jeden zdieľaný generátor, na zdieľanom VPS; rozdiely pod 20% nie sú tvrdenia.
• Obyčajná cesta nebola meraná na VPS ani proti Mosquittu.
• Lighthouse na novom jednoduchom zobrazení nie je potvrdený (staré zobrazenie: dostupnosť 95 alebo viac).
• Bare metal, cena workera na x86_64 na KVM, Firefox a Safari pre emulátor: nemerané.

Čo bude ďalej

• D1: verejný demo broker. Emulátor z prehliadača nemôžeme sprístupniť verejne: žije v karte jedného návštevníka, je 20 až 100-krát pomalší než KVM, nemá prichádzajúcu sieť a zmizne so zatvorením karty; presmerovanie internetu do cudzieho prehliadača by bolo aj zneužitie. Možný je skutočný demo broker: urMQTT na VPS za menom na aldo.tech, so zverejnenou skúšobnou CA, prísnym ACL a malými limitmi. Je to zatiaľ len nápad, nie stavba, a vyžaduje výslovný súhlas na verejné vystavenie.
• Druhé kolo pre jeden tok (vetva perf-single-flow-wip): až keď bude namerané na VPS a zlúčené.
• Obyčajná cesta proti Mosquittu na VPS, prihlásenie a zrušenie účtu pre obyčajný MQTT cez podpísaný riadiaci kanál.
• Po vydaní: bare metal (X12 až X16), IOMMU a Secure Boot, šifrovanie disku.

Kód je na github.com/zeljan-alduk/urMQTT a docs/PROGRESS.md je naďalej jediným zdrojom pravdy o tom, čo skutočne funguje, docs/PERFORMANCE.md o tom, čo je namerané. Pred-alfa, ako predtým; hlásenia chýb a bezpečnostné hlásenia podľa pokynov v SECURITY.md sú vítané.