Windows 10 EULA - som zhrozeny

strepty

Re:Windows 10 EULA - som zhrozeny
« Odpověď #570 kdy: 31. 08. 2015, 16:59:24 »
Trosku od tematu, ale som tiez zhrozeny. Neveril som tomu, ale stalo sa mi to, pod rukami sa mi resetoval Windows 10. Nemal som moznost nic urobit, len zrazu nevypinajte pocitac resetuje sa.  Mac os vyhodi  dotierave okno kde treba nieco stlacit a ked dorobim tak ho stlacim ale resetnut sa pod rukami to je hroza. Ak to urobi este raz tak na ten nb vratim Ubuntu.


ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #571 kdy: 31. 08. 2015, 17:05:22 »
Trosku od tematu, ale som tiez zhrozeny. Neveril som tomu, ale stalo sa mi to, pod rukami sa mi resetoval Windows 10. Nemal som moznost nic urobit, len zrazu nevypinajte pocitac resetuje sa.  Mac os vyhodi  dotierave okno kde treba nieco stlacit a ked dorobim tak ho stlacim ale resetnut sa pod rukami to je hroza. Ak to urobi este raz tak na ten nb vratim Ubuntu.

To bude nějaká nová fíčura, po které uživatelé volali a obzvlášť firemní uživatelé jsou za ni rádi. :D

j

Re:Windows 10 EULA - som zhrozeny
« Odpověď #572 kdy: 31. 08. 2015, 17:45:40 »
To mě zajímá. Jak uděláte transparentní šifrování na FS bez toho abyste měnil on-disk structures? Navíc FAT32 má pro podobné účely rezervované bity a popsané jejich chování, takže ve zvolené implementaci nevidím problém.

Ze byste treba zavedl novou hlavicku souboru, ktera rekne OS, ze se jedna o sifrovany obsah? Zpetna kompatibilita je zarucena. OS, kde to neni implementovano, uvidi jakysi soubor s binarnim bordelem.
Neblbni cece, to by nebyla M$ way, a dokonce by to i fungovalo. A dokonce to tak i funguje - teda pokud si nainstalujes non M$ appky ktery sifrujou jednotlivy soubory.

Stačí na to poštvat implementaci fsck, která dodržuje specifikaci. A protože ve specifikaci se říká, že bity by měly být 0 (alespoň v té vydané, jinou nikdo nikdy neviděl), tak když je najde ve stavu 1, tak je vynuluje. To bude legrace, až se takové zařízení vrátí do Windows 10 a tam budou šifrované soubory rázem nečitelné, protože nemají ty bity v 1.
Kecáte, znovu cut-paste ze specifikace: "Reserved for use by Windows NT. Set value to 0 when a file is created and never modify or look at it after that." Z čeho usuzujete, že by tyhle bity měla "implementace fsck, která dodržuje specifikaci" vynulovat?

Mno dment jako ty samo nedokaze pochopit, ze kdyz mam nastroj na opravy disku, tak bit nastavenej do 1 tam, kde ma byt 0 je jaksi presne jedna z tech chyb, ktere by bylo zahodno opravit, ze.

To by me ty imbecile zajimalo, co asi tak vsechny tyhle veci budou delat se souborem, kterej ma ten bit nastavenej widlema. Nj, POSEROU SE. Protoze je jim predlozeny cosi, co nesplnuje specifikaci.
Jeronýmku, vy ignorante, staré implementace FAT32 samozřejmě soubor nedešifrují a přečtou ho v RAW mode (tj. uvidí data v šifrovaném stavu).

Vsak to davno implementovano je, i pro widle, to jen M$ ma naprosto neschopny (nebo vsehoschopny?) trotly misto programatoru. Muzes nainstalit (i do widli) appky, ktery proste soubor zasifrujou a zadny bity na disku k tomu nepotrebujou.

Jenze to by se M$ po 30ti letech musel naucit pouzivat hlavicky souboru misto nejakych priblblych pripon.
Hlavičky souborů jsou v principu nespolehlivé. To že má soubor na nějakém offsetu pár konkrétních bytů nijak jednoznačně neurčuje jeho typ. To že soubor začíná "Return-Path:" z něj nedělá EML, to že začáná na "SQLite format 3." z něj nedělá SQLite DB file. A například v nešifrovaném souboru .bin můžu mít z mnoha důvodů klidně uložený šifrovaný JPEG ve formátu EFS. Pokud budete používat hlavičky, automaticky ho dešifrujete, a bude to zcela špatně. Podobně můžu mít těch pár bytů, podle kterých byste chtěl rozeznat šifrovaný soubor, náhodou například ve video streamu nebo JPEGu.

Jasne, protoze M$ udela sifrovanej soubor a neumi si k nemu pridat dostatecne jednoznacnou hlavicku. Vis ty trotle, ze na hlavickach je zalozenej celej internet?


Za takovou implementaci šifrování rádi opravdu nebudou, protože jak vidno, tak to není kompatibilní není.
Implementace šifrování na FAT32 je kompatibilní se všemi předchozími implementacemi FAT32, které se drží MS specifikací podle kterých měly být napsané. Jediný problém je u Sound Devices, a to díky tomu že se specifikace nedrželi.

PS: Ale MS jde o to, aby dožduchali všechny uživatele starší verze Windows do desítek a tohle je jeden z háčků. A až bude hromada věcí v cloudu (jakože s Windows 10 to posunuli o několik levelů výš), tak se budou uživatelé (čti ovečky) ovládat zase o něco snadněji.  ;)
Cloud přináší výhody. Například můžete mít ta samá data přístupná z desktopu, notebooku i telefonu. Samozřejmě k tomu ta data musíte uložit na nějaký server, a to obnáší rizika v oblasti bezpečnosti a ochrany soukromí. Pokud vám taková rizika nestojí za přidanou hodnotu (mě rozhodně nestojí), tak data do cloudu neukládejte.

Kompatabilni zcela jiste neni, jak tu uz dobra duse dokazala experimentem, co na to rikas luliku? Hovno vid? Protoze ste mu prave zkurvili jeho zasifrovany data svoji nekompatabilni zmenou FS.

Trosku od tematu, ale som tiez zhrozeny. Neveril som tomu, ale stalo sa mi to, pod rukami sa mi resetoval Windows 10. Nemal som moznost nic urobit, len zrazu nevypinajte pocitac resetuje sa.  Mac os vyhodi  dotierave okno kde treba nieco stlacit a ked dorobim tak ho stlacim ale resetnut sa pod rukami to je hroza. Ak to urobi este raz tak na ten nb vratim Ubuntu.

Heh, muzu potvrdit, mel sem na tom pustenej wireshark, a po cca 2 hodinach sem prisel, a bylo to resetly


Heh, ted sem si vzpomel, existoval kdysi takovej pekne softik jeste pro DOS, a v nem byl popis assambleru, vsech funci DOSu, vsemoznych preruseni atd. Nevzpomenu si jak se to jmenovalo. Ale co si pamatuju je, ze u hromady tech funci byla poznamka, ze jde o nezdokumentovanou funkci. Byly to samozrejme ty nejzajimavejci veci, ktery M$ ve velkym pouzival a ostatnim tvrdil, ze nic takovyho neexistuje.
Nebyl to nahodou SYSMAN ?
Jop, to bude ono asi, jeste k tomu bylo neco podobnyho s podobnym nazvem.


Provedl jsem následující experiment:
1) ve Windows 10 jsem naformátoval flashku FAT32 (4 GB),
2) nakopíroval na ni soubor (log, cca 280 KB),
3) zašifroval,
4) odpojil flashku a připojil na Windows 8.1 (plně aktualizovaný).

Název souboru je obohacen sufixem .PFILE a obsah souboru je samozřejmě nečitelný (zdá se, že se tam objevila nějaká hlavička). Velikost souboru je cca o 4 KB větší.

5) vytvořil jsem adresář na flashce a zkopíroval do něj ten šifrovaný soubor,
6) prohlédl na Windows 10.

Původní soubor je bez problémů čitelný (samozřejmě za předpokladu, že uživatel disponuje příslušným klíčem). Je ale vidět, že FAT32 driver (fastfat.sys) ve Windows 8.1 dodržuje starší verzi specifikace (EFS bit je považován za reserved), takže při vytváření nového souboru nuluje reserved bity v jeho directoory entry. Tudíž zkopírovaný soubor dešifrovat nelze, neb není označen jako šifrovaný (nevím, zda by pomohlo, kdyby tak byl označen např. přímým přístupem na "disk").

Takže tak.

ByCzech:
Co se týče toho ničení dat, můžete se mrknout do zdrojových kódů ovladače fastfat, je součástí balíku Windows Driver Kit. Sice tam nebude nejaktuálnější verze, ale nemyslím, že by zapisování do struktur FS při čtení byla nějaká novinka. Samozřejmě to může být i tak, že dané zápisy provádí nějaký FS filter/minifilter nad instancní daného FS.

Diky, potvrzeni toho, co sme vsichni vedeli predem. Jinak receno, kdyz si typickej BFU bude nosit soubory na flashce, a nejakym omylem si zapne sifrovani, tak o ty soubory proste pri nejblizsi prilezitosti zcela kdekoli prijde. A i kdyz o ne nahodou neprijde, tak mu na 80% mistech kam prijde budou knicemu, protoze je nepujde precist. Eto technika ....

Tak jo, predpokladejme, ze dam na disk binarni data, kde zrovna nahodou na zacatku bude kombinace, ktera odpovida hlavicce MS sifrovaneho souboru. No, vzhledem k tomu, ze dneska par bajtu nikdo neresi, co brani MS, aby si za tu hlavicku ulozil napriklad nejakou dalsi znacku (overeni hlavicky), podle ktereho by vznikla temer jistota, ze dat jsou bud binarni bordel nebo sifrovany soubor? Diskety uz nikdo nepouziva, tak treba deset nabo i dvacet bajtu nikoho nezabije. Jaka je pravdepodobnost, ze vytvorim binarni blob, kde treba 20 bajtu bude stejnych? Krome toho v takovem souboru muze byt treba kontrolni soucet nebo se treba pozna, ze to nejde rozsifrovat. A i kdyby, tak pokud MS do toho nebude zasahovat, nic se nestane. Pokud uzivatel neni zretelne blby, tak si vsimne, ze se soubor rozsifroval jako binarni bordel a vzpomene si, ze to neni sifrovany soubor.

Cece neblbni, jeste bys moh dojit k tomu, ze kdyz uz je soubor sifrovanej, muze byt i podepsanej. Bezne se veci delaji tak, ze mas nekde nejakej identifikator, a kdyz sedi, tak se podivas na zbytek, kdyz ne, tak to neresis. Ostatne, presne stejne funguje ten tux, to ze ma neco na zacatku par bytu jeste neznamena, ze to nutne je obrazek, ale kdyz to obrazku odpovida, tak se du podivat na zbytek toho souboru. Jak nelogicke ...

Nemáme jistotu, že se jedná o identickou kopii, protože přídavné struktury pro EFS jsou neznámé, ale v zásadě souhlasím. Je to škoda.
...
Opravné pokusy jsou jen moje doměnka. Vůbec tomu tak být nemusí. Zdrojáky fastfat jsem komplexně nečetl, jen určité malé části.

... je uplne jedno co se tam deje, vysledek je z pohledu uzivatele zcela jednoznacny - prisel o data a neumi to spravit. A neumi to spravit ani M$, protoze neumi rozpoznat vlastnim systemem zasifrovanej soubor. To je vysledek doslova katastrofalni.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #573 kdy: 31. 08. 2015, 18:47:07 »
Provedl jsem následující experiment:
1) ve Windows 10 jsem naformátoval flashku FAT32 (4 GB),
2) nakopíroval na ni soubor (log, cca 280 KB),
3) zašifroval,
4) odpojil flashku a připojil na Windows 8.1 (plně aktualizovaný).

Název souboru je obohacen sufixem .PFILE a obsah souboru je samozřejmě nečitelný (zdá se, že se tam objevila nějaká hlavička). Velikost souboru je cca o 4 KB větší.

5) vytvořil jsem adresář na flashce a zkopíroval do něj ten šifrovaný soubor,
6) prohlédl na Windows 10.

Původní soubor je bez problémů čitelný (samozřejmě za předpokladu, že uživatel disponuje příslušným klíčem). Je ale vidět, že FAT32 driver (fastfat.sys) ve Windows 8.1 dodržuje starší verzi specifikace (EFS bit je považován za reserved), takže při vytváření nového souboru nuluje reserved bity v jeho directoory entry. Tudíž zkopírovaný soubor dešifrovat nelze, neb není označen jako šifrovaný (nevím, zda by pomohlo, kdyby tak byl označen např. přímým přístupem na "disk").

Takže tak.

ByCzech:
Co se týče toho ničení dat, můžete se mrknout do zdrojových kódů ovladače fastfat, je součástí balíku Windows Driver Kit. Sice tam nebude nejaktuálnější verze, ale nemyslím, že by zapisování do struktur FS při čtení byla nějaká novinka. Samozřejmě to může být i tak, že dané zápisy provádí nějaký FS filter/minifilter nad instancní daného FS.

Diky, potvrzeni toho, co sme vsichni vedeli predem. Jinak receno, kdyz si typickej BFU bude nosit soubory na flashce, a nejakym omylem si zapne sifrovani, tak o ty soubory proste pri nejblizsi prilezitosti zcela kdekoli prijde. A i kdyz o ne nahodou neprijde, tak mu na 80% mistech kam prijde budou knicemu, protoze je nepujde precist. Eto technika ....

Povíme si pohádku před spaním:

Byla nebyla jedna pobočka velké korporace. Pan ředitel má už 3 dny na svém firemním PC i na notebooku Windows 10, které získal upgradem zdarma ze starší verze. "Prý s tím upgradem naši ajťáci měli problém. Na tom rautu co pořádal MS ale říkali, jak je upgrade jednoduchý a zcela automatický. Určitě se ti podivíni zase takhle dělají důležití, aby si mohli říct o větší plat. Tůdle, nevybudoval jsem tuhle pobočku tím, že bych někomu dával peníze za to, co se dělá samo a dotyčný pro to nemusel skoro hnout prstem... Hodně se mi líbí nová funkce šifrování souborů. Už mi nikdo do mých věcí nebude moct strkat nos. Ani ti zatracení ajťáci, kteří se jinak dostanou všude. Zástupci MS mě ale ujistili, že bez klíče jsou bez šance. Paráda. Všechny dokumenty na přenosném disku jsem si zašifroval. Zítra jim to nechám překopírovat na ten nový disk, který jsem je nechal pro sebe koupit. Ani si nevrznou, když by mi do dat chtěli čumákovat. Vždyť mají pitomci pořád ještě Win7, které ani šifrovat neumějí.  A to si je ještě ti hlupáci pochvalují. Takže mají smolíka. To jsem je to převezl."...
Další den ajťáci překopírovali 500 GB dat v souborech s příponou .PFILE na nový 2TB přenosný disk, dokonce zkontrolovali sumy jednotlivých souborů, aby měli jistotu, že se během kopírování neztratil jediný bit (u Windows jeden nikdy neví), starý disk dle firemní politiky zformátovali, pustili na něj důkladné testy povrchu, které zničí poslední zbytky dat, aby zajistili, že pokud půjde starší disk k dalšímu uživateli bude v bezvadném stavu nebo půjde do koše. Přece nechceme, aby se nám po firmě poflakovaly nespolehlivá úložná zařízení. Poslední větší zvíře na to dojelo, když mu selhal disk a dostal od nadnárodního většího zvířete padáka - chudák, mohl se akorát rozhodnout, jestli chce jít z firmy hned nebo až za hodinu. To už se nesmí stát. Šéfovi po obědě předáme nový disk s jeho daty, má telekonferenci s tím nadnárodním šéfem, bude je prý nutně na poradě potřebovat...

Druhý den měla pobočka nové vedení :D

Dobrou noc děti...

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #574 kdy: 31. 08. 2015, 19:16:25 »
Tak on MS mohl udelat neco proto, aby se clovek mene obaval data do kloudu napchat. Data tam mohla jit sifrovana, clovek by si v nejakem onfiguratoru naklikal, ktera se budou sifrovat. Na vsechna zarizeni by si naimportoval klice a bylo by. Sice to neni bombenfest, protoze by se nasli lide, kteri by rekli, ze MS muze krast klice a posilat je do NSA. Ale byla by to aspon jakasi snaha, relativne duveryhodna.
To ovšem vylučuje používání těch dat z webových aplikací, protože ty by ve vašem scénáři zřejmě ty klíče neměly.

Tak jo, predpokladejme, ze dam na disk binarni data, kde zrovna nahodou na zacatku bude kombinace, ktera odpovida hlavicce MS sifrovaneho souboru. No, vzhledem k tomu, ze dneska par bajtu nikdo neresi, co brani MS, aby si za tu hlavicku ulozil napriklad nejakou dalsi znacku (overeni hlavicky), podle ktereho by vznikla temer jistota, ze dat jsou bud binarni bordel nebo sifrovany soubor? Diskety uz nikdo nepouziva, tak treba deset nabo i dvacet bajtu nikoho nezabije. Jaka je pravdepodobnost, ze vytvorim binarni blob, kde treba 20 bajtu bude stejnych? Krome toho v takovem souboru muze byt treba kontrolni soucet nebo se treba pozna, ze to nejde rozsifrovat. A i kdyby, tak pokud MS do toho nebude zasahovat, nic se nestane. Pokud uzivatel neni zretelne blby, tak si vsimne, ze se soubor rozsifroval jako binarni bordel a vzpomene si, ze to neni sifrovany soubor.
To jestli je soubor například šifrovaný nebo komprimovaný na úrovni FS nemůžete určovat z obsahu souboru, protože tak vytváříte závislost na něčem co není nikde specifikované a nemáte to pod kontrolou. Například soubory šifrované EFS si můžete vydumpovat v RAW módu (tedy v šifrované podobě) a uložit do souboru; samozřejmě pak nechcete aby vám je FS dešifroval. Navíc stejnou hlavičkou souboru může použít kdokoliv náhodně nebo systematicky. Vizte co jsem psal o záměně ZIP, JAR, KMZ, KWD, ODT, ODP, OTT, SXC, SXD, SXI, SXW, SXC, WMZ, XPI, XPS a XPT (a nejspíš řady dalších formátů). Obsah souboru je prostě věc aplikace, může v něm být cokoliv včetně hlavičky EFS, a FS se podle toho nemůže a nesmí orientovat. Rozdělení na data souboru a metadata má velmi dobré důvody.

Soucasna nova implementace je jaksi znacne suboptimalni. Jak uz bylo vyse poukazano, sifrovane soubory z Widli 10 asi nepreziji kopirovani na jine medium najinem OS, nez W 10. Uzivatel obdrzi medium s binarnim svincikem a bez diskeditoru se k tem datum uz nikdy nedostane. Predstavte si, jak si treba stara Blazkova koupi novou flashku. Tu da spolu se starou vnukovi, at ji prekopiruje data a starou flashku si necha. Vnuk data presype na Macu a puvodni flasku vymaze a prevalcuje pornem. Stara Blazkova pak zjisti, ze nemuze otevrit sifrovane soubory s recepty na babovku a moravske zeli. Nasledne si nasadi brejle, spusti diskeditor a jde to opravovat.
Samozřejmě starší verze FS neumí features novější verze. Tak už to u dopředné kompatibility bývá.

K omylu dojit muze. Potiz je, ze FAT na nejake sifrovani nebyl od pocatku zalozeny a tak k tomu omylu pri trose stesti nemuze dojit pouze tehdy, kdyz vsichni pouzivaji Widle 10. Tak daleko nejsme a jeste nejakou dobu nebudeme. Tady by byvalo vhodnejsi, kdyby si MS prestal hrat na zpetnou kompatibilitu a prisel s novym FATem, ktery neni zpetne kompatibilni. Pro starsi podporovane Widle pak mohl vydat zaplatu, ktera by do nich podporu FATu s sifrovanim dotlacila. Pri trose slusnosti by vytvorili i zaplatu pro XP, protoze do prechodu na kachliky se lidem moc nechce. Pri formatovani na novy FAT by pak user mohl byt upozornen, ze tim ziska sifrovani, ale prijde o moznost cteni sifrovanych souboru na starych Widlich a eventuelne jinych OS. O tuto moznost strjne prichazi a jeste vznika nebezpeci ztraty dat diky nepodpore sifrovani jinde, nez na W 10, kdy clovek pak uz nic neprecte ani na nich.
Zbourat dopřednou kompatibilitu FAT32 je nesmysl. Když se implementátoři drží specifikace, tak všechno funguje správně. A když se ji nedrží, tak žádné verzování FS nepomůže.
MS by teoreticky mohl vydat patch pro starší verze Windows. Těžko ale vydá patche pro kamery, zvuková záznamová zařízení, MP3 přehrávače, televize, mobily, automobily a hromady dalších zařízení.


Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #575 kdy: 31. 08. 2015, 19:18:03 »
LOL. Lael se opět proflákl. Nejdříve tvrdí, že když jsou bity v jedničce, je to špatně. A teď tvrdí, že by to fsck neměl opravovat ne nuly, když je jednička špatně :D.
LOL. Na ty bity nemáte po vytvoření souboru sahat. Vy byste je pro jistotu znuloval. Mám nápad: jděte přispívat do jádra Linuxu. Není potřeba žádná sabotáž od MS. Bohatě postačíte vy ;)

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #576 kdy: 31. 08. 2015, 19:23:06 »
Ale čtení IDENTICKÉ kopie na Windows 10 následně ne. Což mi přijde úsměvné. Mám úplně kompletní data, mám dešifrovací klíč a nemůžu je přečíst v dešifrované podobě - taková velká firma a takový fail? ...
Jde o identickou kopii dat, nikoliv metadat.

No to je právě ten problém. Čtení souboru nemá co vyvolávat dílčí pokusy o opravy, obzvlášť, když to neopravuje, ale kazí - jo kdyby to opravdu opravilo, tzn. poznalo, že nejde o šifrovaný soubor a smazalo ty bity, tak to by byla jiná, ale i tak si nemyslím, že se má driver FS pokoušet opravovat dílčí chyby FS a už vůbec ne OBSAHU uživatelských dat během čtení - takové akce totiž mají být úkolem komplexní analýzy stavu FS nástroji pro to určenými, když je zajištěno, že se v danou chvíli do toho nikdo jiný nehrabe, jinak si koledujete přesně o to k čemu došlo a jiné průšvihy.
Pokud je soubor šifrovaný, jeho obsahem nejsou uživatelská data. Je v něm informace o klíči, data jsou šifrovaná po blocích atd. Jinými slovy jde o strukturu FS srovnatelnou třeba s adresářem. A jak jste si mohl všimnout, do adresáře (a jiných metadat FS) se běžně zapisuje i při čtení.

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #577 kdy: 31. 08. 2015, 19:25:36 »
...protože když specifikace říká, že tam mají být nuly, tak když tam najde jedničky, tak je logické, že to je špatně a měl by to opravit.
Jenže MS má podle Laela prý specifikaci jinou, jen pro sebe a pro ostatní je specifikace původní. Takže implementace opravného nástroje, který uvede FS do stavu, ve kterém má být dle specifikace, bude dle Laela špatný protože hrabe do bitů, které MS používá ve své extra specifikaci, kde bity už mohou být nejen nenulové, ale můžou se prý na jedna nastavovat... Mám pocit, že jsem se zacyklil :D
Jo, zacyklil jste se. Ta specifikace neříká, že máte bity později nulovat. Naopak jasně říká, že jsou rezervované a nemáte na ně nemáte sahat. Pokud si specifikace vykládáte jak tu předvádíte, tak vizte co jsem psal minule: jděte přispívat do kernelu Linuxu :D

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #578 kdy: 31. 08. 2015, 19:27:20 »
Lael to opět nepochopil. Na Linuxu mi LO i OOo startuje bleskově narozdíl od Windows na stejném stroji. Ale to má z toho, že se nesírá do věcí, kterým nerozumí, např. do Linuxu.
Tak to máme výrazně odlišné zkušenosti. Jestli to nebude tím, že máte zapnutý QuickStarter, který vám LibeOffice zavede při startu. To je obšleh podobné věci z MS Office, kterou MS už tuším více než deset let nepotřebuje.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #579 kdy: 31. 08. 2015, 19:32:03 »
Ale čtení IDENTICKÉ kopie na Windows 10 následně ne. Což mi přijde úsměvné. Mám úplně kompletní data, mám dešifrovací klíč a nemůžu je přečíst v dešifrované podobě - taková velká firma a takový fail? ...
Jde o identickou kopii dat, nikoliv metadat.

No to je právě ten problém. Čtení souboru nemá co vyvolávat dílčí pokusy o opravy, obzvlášť, když to neopravuje, ale kazí - jo kdyby to opravdu opravilo, tzn. poznalo, že nejde o šifrovaný soubor a smazalo ty bity, tak to by byla jiná, ale i tak si nemyslím, že se má driver FS pokoušet opravovat dílčí chyby FS a už vůbec ne OBSAHU uživatelských dat během čtení - takové akce totiž mají být úkolem komplexní analýzy stavu FS nástroji pro to určenými, když je zajištěno, že se v danou chvíli do toho nikdo jiný nehrabe, jinak si koledujete přesně o to k čemu došlo a jiné průšvihy.
Pokud je soubor šifrovaný, jeho obsahem nejsou uživatelská data. Je v něm informace o klíči, data jsou šifrovaná po blocích atd. Jinými slovy jde o strukturu FS srovnatelnou třeba s adresářem. A jak jste si mohl všimnout, do adresáře (a jiných metadat FS) se běžně zapisuje i při čtení.

Pokud je schopnost číst obsah souboru závislá na metadatech, která se nepřenášejí běžným kopírováním či odesíláním raw souboru po síti, netu, emailu a podobně, je to jednoznačně nejdementnější implementace šifrování v dějinách ukládání dat. :D Tahle pro jistotu mrví i data, která se šifrovaným souborem nemá nic společného :D. Že on to nakonec do Windows psal ten sousedovic kluk v rámci letního tábora? :D

Čím to, že implementace transparentního šifrování, se kterými jsem měl tu čest s kopírováním či přenášením mezi počítači nemají problém ani při průchodu různými FS či médii, včetně různých síťových souborových systémů, odesílání skrz email, balením a rozbalováním do různých archívů ap.? Jo aha, protože to programovali páni Programátoři (s velkým P) ne šílenci z MS :D

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #580 kdy: 31. 08. 2015, 19:32:21 »
Ono to zas tak jednoduche neni:

Vzhledem k tomo ze autoritativni zdroje ( LaelOphir ) rikaji, ze specifikace pozaduje pri vytvareni soboru nastavit reservovane bity na 0 a pak uz je nikdy nekontrolovat zksme tuhle hypotezu:

Dejme tomu ze firma SD napise program na spojovani souboru: ten vytvori, presne podle specifikace specifikace novy soubor s obema bity nastavenymi na 0 a postupne do nej zkopiruje data ze vstupnich souboru, ktere maji tyto bity != 0. Vysledek asi nebude fungovat ale bude podle specifikace.
Tím autoritativním zdrojem nejsem já, ale specifikace FAT32, kterou jsem opakovaně linkoval.

Samozřejmě staré implementace FAT32 nemohou umět to o co byly rozšířené nové specifikace. To je omezení dopředné kompatibility. Ext2 také neumí třeba přehrávat žurnál ext3. V případě FAT32 můžete už na Windows 95 OSR2 přečíst soubory zapsané na Windows 10, samozřejmě pokud nepoužijete věci které Windows 95 OSR2 neumí (třeba to šifrování). Nicméně šifrovaný soubor uvidíte na staré implementaci FAT32 s příponou .PFILE (tady děkuji MD že na to upozornil), takže by s tím neměl být problém.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #581 kdy: 31. 08. 2015, 19:34:37 »
Lael to opět nepochopil. Na Linuxu mi LO i OOo startuje bleskově narozdíl od Windows na stejném stroji. Ale to má z toho, že se nesírá do věcí, kterým nerozumí, např. do Linuxu.
Tak to máme výrazně odlišné zkušenosti. Jestli to nebude tím, že máte zapnutý QuickStarter, který vám LibeOffice zavede při startu. To je obšleh podobné věci z MS Office, kterou MS už tuším více než deset let nepotřebuje.

Už jsem vám v jiných diskuzích vysvětlil, že QuickStarter nepoužívám, vemte si prosím už laskavě pořádné kladivo a vytlučte si tenhle debilní argument z palice a nabijte si tam tuhle informaci, ať na to pořád nemusím narážet. LO mi startuje bleskově bez QuickStarteru.  Dokud si to do hlavy nedostanete, neozývejte se prosím!

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #582 kdy: 31. 08. 2015, 19:38:25 »
Ono to zas tak jednoduche neni:

Vzhledem k tomo ze autoritativni zdroje ( LaelOphir ) rikaji, ze specifikace pozaduje pri vytvareni soboru nastavit reservovane bity na 0 a pak uz je nikdy nekontrolovat zksme tuhle hypotezu:

Dejme tomu ze firma SD napise program na spojovani souboru: ten vytvori, presne podle specifikace specifikace novy soubor s obema bity nastavenymi na 0 a postupne do nej zkopiruje data ze vstupnich souboru, ktere maji tyto bity != 0. Vysledek asi nebude fungovat ale bude podle specifikace.
Tím autoritativním zdrojem nejsem já, ale specifikace FAT32, kterou jsem opakovaně linkoval.

Samozřejmě staré implementace FAT32 nemohou umět to o co byly rozšířené nové specifikace. To je omezení dopředné kompatibility. Ext2 také neumí třeba přehrávat žurnál ext3. V případě FAT32 můžete už na Windows 95 OSR2 přečíst soubory zapsané na Windows 10, samozřejmě pokud nepoužijete věci které Windows 95 OSR2 neumí (třeba to šifrování). Nicméně šifrovaný soubor uvidíte na staré implementaci FAT32 s příponou .PFILE (tady děkuji MD že na to upozornil), takže by s tím neměl být problém.

S žurnálem Ext2 vs Ext3 je to zcela nerelevantní příklad. To nijak neovlivňuje uživatelovat data. Stejně jako neovlivňuje překopírování dat z FAT (bez žurnálu) na NTFS (s žurnálem) a následné čtení (tedy pokud ta data nebyla šifrovaná novým dementním systémem). :D

Problém s tím je, napsali jsme jaký. Ztrácejí se infromace, které způsobí, že stejný soubor s příponou .PFILE jednou rozšifrovat jde a po zkopírování nejde - EPIC FAIL!

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #583 kdy: 31. 08. 2015, 19:39:51 »
...protože když specifikace říká, že tam mají být nuly, tak když tam najde jedničky, tak je logické, že to je špatně a měl by to opravit.
Jenže MS má podle Laela prý specifikaci jinou, jen pro sebe a pro ostatní je specifikace původní. Takže implementace opravného nástroje, který uvede FS do stavu, ve kterém má být dle specifikace, bude dle Laela špatný protože hrabe do bitů, které MS používá ve své extra specifikaci, kde bity už mohou být nejen nenulové, ale můžou se prý na jedna nastavovat... Mám pocit, že jsem se zacyklil :D
Jo, zacyklil jste se. Ta specifikace neříká, že máte bity později nulovat. Naopak jasně říká, že jsou rezervované a nemáte na ně nemáte sahat. Pokud si specifikace vykládáte jak tu předvádíte, tak vizte co jsem psal minule: jděte přispívat do kernelu Linuxu :D

Specifikace podle vás říká, že bity mají být v nule. Jsou li tam jedničky, je to chyba a je třeba ji opravit. To pochopí i dítě z mateřské školky. Tedy pokud nebude mít stejnou osobnostní poruchu jako vy :D

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #584 kdy: 31. 08. 2015, 19:41:21 »
Neblbni cece, to by nebyla M$ way, a dokonce by to i fungovalo. A dokonce to tak i funguje - teda pokud si nainstalujes non M$ appky ktery sifrujou jednotlivy soubory.
To by samozřejmě nefungovalo, protože obsah souborů je věc aplikace, může tam být cokoliv, a tedy je to nespolehlivý detekční mechanismus.

Mno dment jako ty samo nedokaze pochopit, ze kdyz mam nastroj na opravy disku, tak bit nastavenej do 1 tam, kde ma byt 0 je jaksi presne jedna z tech chyb, ktere by bylo zahodno opravit, ze.
Milý nedouku, ta specifikace zcela jasně říká, že máte na začátku nastavit bity na nulu a dál se o ně nestarat, protože jsou rezervované. Skoro ani nepřekvapí, že zrovna vy to čtete jako "tohle musí být vždy na nule". Čtete to samozřejmě úplně špatně.

Jasne, protoze M$ udela sifrovanej soubor a neumi si k nemu pridat dostatecne jednoznacnou hlavicku. Vis ty trotle, ze na hlavickach je zalozenej celej internet?
Jenže ty hlavičky jsou dané standardem, a nemohou být zaměněny s obsahem paketů, tedy uživatelskými daty. Naopak obsah souboru je zcela v režii aplikace, a mohou v něm být jakákoliv aplikační data, včetně libovolné hlavičky. Až pochopíte rozdíl mezi data a metadaty, přijďte zpátky si sypat popel na hlavu.

Kompatabilni zcela jiste neni, jak tu uz dobra duse dokazala experimentem, co na to rikas luliku? Hovno vid? Protoze ste mu prave zkurvili jeho zasifrovany data svoji nekompatabilni zmenou FS.
Stará implementace FS umí přečíst to co je zapsané bez nových features, tedy v tomto případě bez šifrování. Což je naprosto v pořádku.