Dotaz: Šifrovanie

[Tom]

Dobrý deň,

Potreboval by som váš názor. Idem robiť novú inštaláciu a plánujem šifrovanie disku. Doteraz som používal rozloženie MBR s tým, že disk bol plne šifrovaný pomocou LUKS a heslo sa zadava do Grubu. Ale špekulujem, že by som tentoraz použil UEFI a ak to pôjde aj Secure boot. Moja otázka je, ktorá varianta je podľa vás bezpečnejšia?

Ďakujem za argumenty

Odpovědi

[X]

TPM jsi neuvazoval?

[Tom]

Môj cieľ je čo najbezpečnejši systém. Kedže som zatiaľ TPM nepoužíval, netuším ani ako ho pri inštalácii zahrnúť. Ale vyhradil som si čas na experimenty.

Distro Arch based

[wtf]

Nejbezpecnejsi a Arch? Sorry, to nejde dohromady. Respektive jednoho dne po nahodnem trolling updatu to bude tak bezpecny, ze se tam nedostanes ani sam a nenabootujes.

[lol]

chage -E 0 root

[.]

a? prd, can't access volume

[Max]

Tak UEFI je dnes standard, nepřemýšlel bych nad něčím jiným. Secure boot také není problém, musíš si jen vytvořit vlastní klíče, které si nahraješ do UEFI a budeš si vše podepisovat pomocí sbctl, viz: Unified Extensible Firmware Interface/Secure Boot .
Zdar Max

[pavele]

Je tedy možné šifrovat kompletně celý disk, včetně třeba /boot?

[Peter Golis]

AJ boot keďže GRUB má moduly aj na LUKS. Pri EFI partícii je to trošku zložitejšie.

[Tom K]

Ano, ale jiným způsobem.
Klíčové slovo je OPAL2 a jde to ikdyž v BIOSu není podpora pro nastavení nebo dotaz na heslo k disku.

[TechnikTom]

Já myslím že ano, aspoň takhle standardně zašifruje disk Ubuntu.

Zapnete PC, musíte zadat heslo k disku a až pak vám najede Grub menu, kde si můžete milostivě vybrat třeba start jiného OS.

Fakt super funkce.

Dřív (18.04) šel zašifrovat jen disk s OS a i uživatel neznalý hesla mohl spustit jiný OS nebo se tento mohl spustit automaticky.

Toho teď jako BFU nejsem schopen dosáhnout. Zkoušel jsem i instalaci na předem vytvořený šifrovaný oddíl, ale neuspěl jsem. Věřím, že to asi jde, ale bude to chtít víc "kouzlení" :o)

[Max]

EFI oddíl nezašifruješ. UEFI z něj potřebuje číst. Ale to by nemělo ničemu vadit, protože ten grub budeš mít podepsaný a při jakékoli změně / útoku apod. o tom budeš vědět, protože nebude sedět podpis a nenabootuješ.

Pokud by jsi chtěl zašifrovat komplet disk, tak bys musel použít fci šifrování onoho disku. To bych ale nedělal, protože se tím spoléháš na černou skříňku, která v klidu může mít nějaká zadní vrátka.
Zdar Max

[frufru]

Jak se tedy dostanu ke systemu OS, když mi vymění v efi všechny zavaděče přes UEFI? Jsou to pro mne kouzla s šifrováním, ale při instalaci se tam snad zapíše zavaděč instalace. Při upgrade jádra na vyšší verzi to budu muset znova podepsat? Pak ale nebude souhlasit s instalačním. Fakt kouzla a hodně se v tom ztrácím. Zkoučel jsem to ve fedore 40, když jsem do NTB doinstaloval Nvidia driver a chtěl použít UEFI. Prostě jsem to nerozchodil. A podepisovat po každé změně jádra?

[Max]

Ano, máš hook, který ti to jádro při každé změně automaticky podepisuje.
Když ti někdo smaže / odstraní soubory na EFI oddílě, tak je znovu obnovíš / nabootíš z flashky apod., ne? Nevidím problém.
Zdar Max

[frufru]

Když jsem podepisoval jádro na fedora 40, tak jsem to musel hledat po netu. Dělal jsem to přes terminál a ručně. Žádný hook jsem nenašel. A docela se děsím, že bych si ten hook měl napsat ve skriptu, abych nemusel po každé změně jádra zase hledat a měnit ručně.

[Max]

Vše je popsáno v tom linku, co jsem dal hned na začátku, včetně automatizace. Samo, že ArchLinux, ale snad každý distro na toto bude mít KB.
Zdar Max

[Luky]

OpenBSD sifruje aj swap komplet cely disk jedine pri bootu treba zadat heslo ale zalezi na co to chces openbsd toho moc neumi

[Andrej]

Swap nemá existovat.

Swap šifruje samozřejmě každý systém, který podporuje šifrování disku. (Jaký by jinak asi mohlo mít smysl ukládat kus RAM v plaintextu? To by pod celým šifrováním výrazně podřezalo větev.)

OpenBSD nepodporuje rozumně SMP, takže nebrat.

[k3dAR]

a hibernovat se ma na derne stitky ty ynteligente?

[Andrej]

Máš tak krátkou paměť, nebo to jen předs(t)íráš? Historie na ABCLinuxu napoví, že jsem tohle (také tobě) už několikrát vysvětloval. Tak si to zase zopakujeme; opakování je fotr moudrosti:

• Swap má být soubor, ne oddíl, kvůli flexibilitě.
• Hibernace ztratila výhody, protože moderní notebook vydrží uspaný do RAM řádově týdny. Hibernace dlouho trvá, ve srovnání s uspáním do RAM.
• Útoky kapalným dusíkem jsou málo účinné od dob, kdy i spotřební notebooky a desktopy začaly používat TME nebo SME.
  (Jiří Paroubek: Kdo z vás to má?! Andrej: Moje 3 roky staré Lejnovo to má! Můj 5 let starý Ryzen to má!)
• Dokonce i s nešifrovanou RAM máme cryptsetup luksSuspend a cryptsetup luksResume, i když systemd je nepodporuje bez vydatného přesvědčování — TPM2 to the rescue. (Implicitně systemd-homed pomůže, ale pouze použijeme-li LUKS loopback místo Btrfs subvolume, argh.)

Résumé: Ideálně se hibernovat nemá. A když už, má se hibernovat do souboru, v souladu s pravidlem „nedělit, nedělit, nedělit“.

[tom]

Dakujem za reakciu.

Cielom nie je, aby bol notebook super bezpecny, kedze je to stara sunka z roku 2012. Skor sa chcem nieco naucit a trochu mat pokojnejsie sny. Viem,ze zrucnemu utocnikovi,toto zrejme nepredstavuje prekazku. V minulosti som pouzival, LUKS+LVM+BTRFS. Teraz som LVM vyhodil, pretoze je to zbytocna medzivrstva a chcem pouzivat snapshoty.

Chapem dobre mienenu radu o hibernacii no aj tak by som rad hibernovanie pouzival.

Problem je,ze neviem prinutit zasifrovanu swap particiu, aby sa v GRUBE odsifrovala a mountla. Skusal som kadejake triky v grub.conf aj crypttab.Ked vsak swap particiu manualne odomknem a mountnem tak funguje a mozem hibernovat.

V grub.conf mam

GRUB_CMDLINE_LINUX="cryptdevice=UUID=b85d8f4d-e220-4000-b3b9-464bc5fc04e8:cryptroot 
cryptdevice=UUID=3fd46804-fda5-48bb-9a64-325acce919a7:cryptswap root=/dev/mapper/cryptroot
resume=/dev/mapper/cryptswap"

a v crypttabe

cryptswap	UUID=3fd46804-fda5-48bb-9a64-325acce919a7	none	swap,luks

Niekde som sa docital,ze je mozne vytvorit kluc, ktory sa ulozi na root particii a tym by sa docielilo automaticke oddomknutie swapu ?

Dakujem za rady.

[tom]

Este som zabudol.Obe particie root aj swap som zasifroval tym istym heslom.

[k3dAR]

naopak mam pamet dobrou a vim ze tu dokola pises nesmysly...
- s lvm si muzu swap zmensovat/zvetsovat bez problemu a nemusim pouzivat ohejbaky s file swapem
- hibernace porad vyhody ma, nevim jak dlouho vydrzi ma T480 v suspendu, ale novejsi moderni nb me nezajimaji kvuli nemoznosti 7rade ala ibm klavesnice
- nejde o utok s kapalnym dusikem, ale o to ze pri resume ze suspendu je luks odemcen a teoreticky(?) lze zneuzit nejake diry v lockscreen/screensaveru (to by mohlo resit suspend&resume luksu jak naznacujes, naposledy sem na to koukal pred par lety a prislo mi to zbytecne sr&ni oproti tomu jednoduse proste hibernovat

[Andrej]

- s lvm si muzu swap zmensovat/zvetsovat bez problemu a nemusim pouzivat ohejbaky s file swapem

Srovnáváš nebe a dudy a ještě k tomu vzhůru nohama.

LVM je zoufalý ohejbák, zatímco soubor je … prostě soubor. Změna swapovacího souboru je „jednoduše“ (jednoduše z hlediska rozhraní, ne nutně z hlediska implementace) změna souboru. Otázka sekund.

Přesun prostoru mezi LVM oddílem pro swap a pro FS je (přinejmenším) voser. Chci víc swapu? No tak jo. Zmenšit FS. (Malinko trnout, ale jo, ono to snad bude fungovat.) Zmenšit LV. Třikrát se ujistit o počtu extentů (obvykle divné velikosti), jestli tomu FS neuseknu konec a jestli tam nenechám moc rezervy. Bezva. Přidat uvolněné extenty ke swapovacímu LV. Zvětšit swap. (Jde to už aspoň bez odmountování?) Obrácený postup je podobný voser.

A když zrovna nepřelévám místo mezi swapem a „hlavním“ oddílem, mám tam zbytečnou vrstvu LVM, která tam sedí jako žába na prameni a nic užitečného nedělá.

[k3dAR]

zmena swapovaciho lv je jednoduse zmena lv, otazka pul vteriny...
(necham stranou ze zmenu swapu udelam parkrat za zivot daneho HW, kdyz mu rozsirim ram)
v vg mam samozrejme volne misto, takze nemusim jine lv zmensovat...

cat `which swapresize`
#!/bin/bash
swapoff -a
lvresize -L ${1} /dev/n4t/swap
mkswap -U $(blkid -o value -s UUID /dev/n4t/swap) /dev/n4t/swap
swapon -a

time sudo swapresize +16G
  Size of logical volume n4t/swap changed from 33,00 GiB (8448 extents) to 49,00 GiB (12544 extents).
  Logical volume n4t/swap successfully resized.
mkswap: /dev/n4t/swap: pozor: odstraňuje se starý vzorec swap.
Vytváří se odkládací prostor verze 1, velikost = 49 GiB (52613345280 bajtů)
žádná jmenovka, UUID=ab0b3b02-54fc-4a6c-a886-480e0ddccad8

real    0m0,440s
user    0m0,024s
sys     0m0,041s

[tom]

Sa tu rozprudila diskusia, len trochu odbocila od mojho problemu.Otvaranie swap particie som vyriesil custom openswap hookom v initramfs pomocou kluca na root particii. Problem je, ze po nastartovani Xfce nemozem hibernovat. Proste ma to vrati na lockscreen.Skusil som aj aj Mate a rovnako.

swapon -s
Filename				Type		Size		Used	Priority
/dev/dm-1                               partition	9314300		0	-2

Som stravil dost casu hladanim odpovede, no bez vysledku.V /etc/default/grub mam>

GRUB_CMDLINE_LINUX_DEFAULT="cryptdevice=UUID=b85d8f4d-e220-4000-b3b9-464bc5fc04e8:cryptroot 
cryptdevice=UUID=3fd46804-fda5-48bb-9a64-325acce919a7:cryptswap root=/dev/mapper/cryptroot
resume=/dev/mapper/cryptswap    loglevel=3 quiet"

Resume som skusal aj s UUID swap particie.

Po spusteni mi initramfs spusti a pocka kym zadam heslo do root particie, spusti sa openswap hook. A vyhodi>

Error:resume: no device specified for hibernation.

Ked sa prihlasim do Xfce tak ako pisem vyssie je swap particia aktivovana

Hooky v mkinitcpio.conf mam v spravnom poradi. Mate nejaky napad? Dakujem

[tom]

Tak nakoniec som zistil,ze som blbec, nedavno som rozsiril ram a neuvedomil som si to pri vytvarani swap particie jednoducho bola mala.S pomocou ChatGPT a archwiki som vytvoril swapfile a ten pridal do fstab a grubu. Teraz to funguje.

Avsak by som v buducnosti rad zmensil luksRoot a uvolnene miesto pridal do luksSwap. Ma niekto skusenosti ako je to so zmensenim BTRFS, co urobit apod.Ze vraj je to riskantnejsia operacia.

Dakujem

[xxl]

Btrfs nemá rád swapfile, pokud je vytvořen nad více disky nebo má jiný než single data profile. Takže vytvářet nad několika nedělenými disky s btrfs cryptovaný swapfile a ještě chtít, aby se do něj dalo hibernovat, může být poněkud problém.

There are some limitations of the implementation in BTRFS and Linux swap subsystem:
    filesystem - must be only single device
    filesystem - must have only single data profile
    subvolume - cannot be snapshotted if it contains any active swapfiles
    swapfile - must be preallocated (i.e. no holes)
    swapfile - must be NODATACOW (i.e. also NODATASUM, no compression)

[Andrej]

Pokud by byla řeč o notebooku a pak zas hned o uspávání a probouzení s více disky, vypadá to na nedostatečně ukotvený „kontext“ celé cebaty. Ne že by dnes 17" „mobile workstation“ nemohl mít třeba 4 SSD, to sice jo, ale asi to nebude případ většiny notebooků.

Pokud by byla řeč o hibernaci a probozuení desktopu — probůh, proč? Boot je mnohem rychlejší než probuzení z hibernace. Stav uživatelského rozhraní se dá (v rozumných uživatelských rozhraních) uložit / obnovit. Neuložená data mají být … ehm, uložená, pokud možno automaticky, bez sázek do loterie, aby uživatel neztratil víc než (dejme tomu) pět minut práce, stane-li se něco neočekávaného. Hibernace nepomáhá, jenom všechno „činí méně předvídatelným”: Když po dnešní aktualizaci glibc a systemd zahibernuju, probudí se mi to pak…? Možná jo, možná ne, nechci to zkoušet.

Pravda, většina pokročilých vlastností Btrfs zatím není se swapovacím souborem podporovaná. Je jistě mrzuté, když tak běžná věc jako zálohování (každodenní / každohodinový snapshot + synchronizace diffu od minulého snapshotu se zálohou) vyžaduje deaktivaci / reaktivaci swapovacího souboru. Nicméně vzhledem k tomu, že jsem swap posledních cca 15 let nepoužíval, mě taková věc ovšem trápí poměrně málo. A nedivím se, že na doplnění zrovna těchto funkcí (pokud vím) nikdo nepracuje.

[xxl]

No, já tedy nad btrfs v single data profilu klidně swapfile používám. A při snapshotování ho deaktivovat nepotřebuji.

Ale pokud chci mít swap s btrfs přes více disků, tak prostě ty disky nadělím na partišny a nazdar bazar. Nejaké hrátky s loop device, které by sice možná fungovaly, nehodlám v reálu provádět.

Hibernaci jsem nepoužil, ani nepamatuji.

[Peter Golis]

Najbezpečnejší systém je ten, čo má overiteľnú funkcionalitu. A to vrátane HW komponentov a ich Firmware. Toľko ku otázke vypracovania domácej úlohy. Odovzdávaš ju až po troch kráľoch?

[reb]

Nejjednodušší mi stále přijde používat SATA password, alespoň na notebooku. Umí to každý nb a disk a nemá to žádný overhead (v porovnání s šifrováním na úrovni OS). A bezpečné pro běžné případy jako je krádež nebo ztráta to je dostatečně.

[raven4]

Dobry den preji.

Je zde jeste dalsi moznost :

Disk si CELY zasifruj pomoci cryptsetup+luks za pouziti varianty DETACHED header = na disku NEBUDE zadna realna/skutecna luks hlavicka a tudiz ani masterkey = tzn ze pokud nekdo poridi KOPII takoveho disku (napr. Policie, evil-maid) je k nicemu, jen zmet nul a jednicek.

Bootovani pak probiha z nejakeho specialniho externiho flashdisku s MIMORADNYM zabezpecenim (tj USB disk chraneny HW sifrovanim, VLASTNI klavesnici a vojenskou certifikaci), prikladem budiz treba Kingston Datatraveler2000 (dale DT2000). Doporucuji nastudovat moznosti tohoto disku ci obdobnych alternativ.

Dulezite je, ze luks hlavicku (detached header) vc. masterkey ( potrebnou pro odemceni hlavniho disku ) mas ulozenou v initrd na te bootovaci flesce DT2000 a flashka sama je chranena svou vlastni klavesnici, tj 8-16 mistnym PINEM - spravny PIN flasku odemkne (a lze tak z ni nabootovat), opakovany spatny PIN flasku vymaze. DT2000 muzes po zadani spravneho PINu odemknout+prepnoput do read-only modu, takze boot data vc. luks hlavicky nelze (nahodne) modifikovat. Jednou za cas kdyz si chces vygenerovat novy kernel+initrd pak pomoci PINu prepnes DT2000 do read-write modu, ulozis co potrebujes a pote flasku opet prepnes do read-only modu.

[Andrej]

Nápad s detached LUKS hlavičkou je fajn, ale zbytek už je iluze zabezpečení, což může být horší než absence zabezpečení.

… flashdisku s MIMORADNYM zabezpecenim … USB disk chraneny HW sifrovanim …

To↑ není mimořádné, nýbrž podřadné zabezpečení. (Mimochodem, co je to HW šifrování? Nic takového dnes totiž neexistuje. Éra Enigmy je přece jen dávno pryč.)

Doporucuji nastudovat moznosti tohoto disku ci obdobnych alternativ.

Což nelze, protože děravý proprietární sajrajt není jak „prostudovat“. Kde najdu zdrojáky od toho „hardwarového“ (ha ha ha) šifrování? Takové informace nejsou veřejně k dispozici. Lze všeho všudy uzavírat sázky, jak brzy tu „ochranu“ někdo prostřelí.

…opakovany spatny PIN flasku vymaze…

Ovšem s výjimkou zadních vrátek pro policii, hlavně ve státech, které by správně nad majitelem flashky takovou moc mít vůbec neměly.

[Peter Golis]

í jak „prostudovat“. Kde najdu zdrojáky od toho

Ak robíš pre trojpísmenkovú agentúru, tak si môžeš z peňazí daňových poplatníkov zaplatiť za súčinnosť pri audite daného HW, alebo môžeš využiť OpenHW alternatívu, myslím že nejaký YubiKey sa chválil kadečím. Otázkou je či kontrolovaný dodávateľ poskytne pri audite aspoň relevantné informácie.

Nuž, ale pôvodná otázka mi pripomína nepremožiteľného ktorý sa tu chvastal že navrhol mafiánom barák aj s kompletným zabezpečením ale nevedel urobiť predlžovačku na USB myš. A to už len tým, že Grub Legacy sa už dávno nevyvíja.

[raven4]

uzivatel Andrej ocividne pise aniz by si prostudoval info k produktu.

Takze Datatraveler2000 nese certifikaci FIPS 140-2 Level 3, novejsi produkt Ironkey 200 od teze firmy nese certifikaci FIPS 140-3 Level 3. Obe certifikace jsou dostatecne k tomu aby takoveto zarizeni mohlo byti uzivano ve strukturach vladnich organizaci USA jako FBI nebo napr ve strukturach NATO.
Aby produkt takovou certifikaci ziskal musi splnit prisna kriteria dle pozadovaneho standardu.


offtopic:
paklize ze uzivatel Andrej mluvi o " ... iluze zabezpečení ..." pak vlastne rika ze vsechny standardy a certifikace jsou k nicemu


Zpatky k produktu...

Oba zminene produkty v sobe obsahuji mimojine:
1) vlastni PIN klavesnici
2) vlastni LiPo baterii => takze zarizeni lze odemknout ci napr smazat sifrovaci masterkey KDYKOLIV a KDEKOLIV BEZ vlozeni do USB pocitace ... vse pomoci vlastni PIN klavesnice
3) chip ktery provadi AES_XTS 256bit sifrovani, takze samotne fyzicke uloziste obsahuje data jiz v sifrovane podobe
4) cele zarizeni je uvnitr zalito nejakopu pryskyrici (toto je vyzadovano mimo jine onimi FIPS 140-2 nebo FIPS 140-3 L3 standardy), ktera zajistuje jednak "vode odolnost" dle IP6x / IP5x a dale ma zajistit, ze pri pokusu o nasilne otevreni pouzdra flesky dojde i k umyslnemu poskozeni a tedy znehodnoceni vnitrni elektroniky

Samozrejme nelze hodnotit vnitrni firmware, to je vzdy tajemnstvim vyrobce, toto se tyka jakehokoliv proprietarniho non-open-source reseni, zde musime duverovat onem FIPS standardum a renome firmy Kingston

btw. v pripade zajmu lze nalezt zminene produkty treba na Alz***vi (nedealm reklamu, jen zminuji dostupnost)


Odkaz na datasheets:

DataTraveler2000
https://www.kingston.com/datasheets/DT2000_en.pdf

IronKey 200
https://www.kingston.com/datasheets/IKKP200_en.pdf

obdobny produkt jine firmy napr.DataShure iStorage

[Peter Golis]

S tým FIPS by som bol opatrný, nikde neuvádzajú že majú tie zariadenia plnú certifikáciu a jeden uvádza dokonca len "pending".

Aby to nebolo s tou certifikáciou podobne ako keď som si kúpil odhlučnený externý disk ktorý má nejakú vojenskú certifikáciu. Kupoval som ho ako tichý model bez navýšenia ceny oproti iným externým diskom. Tichý bol kvôli silikónovému obalu a silikón je nielen pružný ale je aj odolný voči teplotám. Takže z celého šrumca certifikácii má odolnosť len voči pádu z barového pultu (z výšky 1,2 m) a trochu je odolný aj proti ohňu. A mám to bez príplatku.

[pavele]

Ještě k těm FIPS a podobným certifikacím - myslím, že třeba Red Hat vyhazuje společně s Microsoftem hodně peněz za to, aby byl systém certifikovaný pro konkrétní použití (třeba vojenské v USA).

Proto má v základu tak málo balíčků.

[frufru]

Třipismenkové agentury mají určitě lepší způsob jak se dostat k datům. Viz. : https://www.root.cz/clanky/minix-je-zrejme-nejrozsirenejsim-systemem-je-ukryty-v-procesorech-intel

Hlídat pár 281 politiků ve sněmovně a k tomu pár perspektivních pro budoucí použití nedá takovou práci. U mobilu je to to samé. Tam není jen jeden procesor. Jen tak zamyšlení.

[Peter Golis]

Keď radšej nakupuješ cudzí alebo zahraničný tovar a nenavrhneš si ho sám, tak si nemôžeš byť istý či bude spĺňať tvoje bezpečnostné požiadavky. Istotu môžeš mať až po detailnej kontrole daného produktu. A je len na tebe do akej hĺbky to budeš kontrolovať.

To platí aj mimo kybernetiky, a mimo trojpísmenkových agentúr.

[pavele]

A teď si představ, že si v rámci bezpečnosti navrhneš všechno sám:

- Budeš si muset vyrobit sám všechny součástky, od procesoru po poslední odpor a krabičku, všude může být backdoor.

- Sám si navrhneš "bezpečný" software včetně šifrování a vyhneš se jakékoliv kontrole nebo certifikaci. Bude to děravé jako řešeto.

- Lidi, které použiješ na výrobu hardwaru a softwaru budeš muset utratit, aby nic neprozradily (chyby v návrhu atd.)

[Peter Golis]

A teraz si predstav že v EÚ sa vyvinulo napríklad nejaké cloudové riešenie zvané Nextcloud. Aký máš dôvod odvádzať peniaze na iný kontinent za cloudové riešenia z krajiny kde platí Patriot Act a zároveň neplatí GDPR, namiesto toho aby si podporil vývoj a údržbu Európskej firme (stojacej za daným produktom) ktorá je lokálnym daňovým subjektom plne spadajúcim pod Európsku legislatívu?

[RealJ]

To tve kouzelne evropske reseni je leda tak pro domaci nasazeni a mozna pro male firmy. Jak nasadim next cloud pres 5 kontinentu s redundanci dat pres 3 kontinenty? Nijak. U aws si klidne mohu rict ze chci mit data v 5ti datacentrech a kazdy uzivatel bude pristupovat k tomu nejblizsimu. Nextcloud vlastne neumi ani active active reseni. K tomu patriot act - ty si myslis, ze v CR treba BIS nema pristup ke tvym datum? Kdykoliv se ji zalibi tak ti prolezou tve data. Policie k tomu potrebuje soudce a povoleni, BIS nic takoveho nemusi resit.

[Peter Golis]

Amazon odkedy poskytuje napríklad telekonferencie alebo kolaboráciu pri nielen zdieľaní dokumentov, ale napríklad aj pri ich editácii bez potreby lokálnej inštalácie kancelárskeho balíka tak ako Nextcloud? To HA nad ktorým súchaš nohami ti poskytne lokálny poskytovateľ, napríklad Ionos SE alebo určite nájdeš aj niečo v krajine kde žiješ. Ak sa ovšem vymaníš z bubliny ktorá ťa vo vegetatívnom stave chráni pred realitou.

A Tebou spomenutý BIS spadá pod Európsku legislatívu, takže nemôže exponovať dáta európskych občanov bez ich súhlasu. Skús si aspoň zbežne pozrieť znenie toho aktu čo som spomínal, a možno pochopíš že napríklad americkým trojpísmenkovým agentúram nič nebráni exponovať akékoľvek nimi vlastnené dáta občanov európpy, a americké spoločnosti sú povinné tieto dáta im dodať. A to aj keď sú tie spoločnosti klasifikované ako GDPR Processor, alebo priamo spadajú pod Európsku legislatívu ktorá im to zakazuje.

[Andrej]

J.e.ž.i.š.m.a.r.j.a. Pane profesore, máme tu exemplář.

Zdrojáky od toho „produktu“ jsou kde? Prosím odkaz na repository.

Jasně. Používá to prý NATO a PODTO a VEDLETOHO. Všichni!!!

• Tu samou verzi? Kde to najdu? Kde to ověřím? Kde jsou zdrojáky? Kde je verifiable build?
• A hele, že jsou to všechno přesně ty instituce, které potřebují dokonale fungující escrow na všechny své minulé, současné i budoucí zaměstnance. N.á.h.o.d.i.č.k.a.

Info k produktu. Prý jsem si to neprostudoval. To je jako co? Pitomé reklamní žvásty? Ty mají být info?

Chci opravdové info k produktu. Zdroják. Kde je zdroják?

(Co takhle přestat dělat užitečně-idiotskou reklamu rádoby-zabezpečenému scamu se zadními vrátky od stodoly? Jenom návrh, podnět k úvaze.)