Windows 10 EULA - som zhrozeny

[Honza]

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 ?

[Reklama]

[MD]

To jsme ale říkali. Děkuji za potvrzení, že implemetace šifrování je špatná i z tohoto pohledu.

No, pokus o čtení šifrovaných souborů na starších verzích Windows (alespoň 8.1) se zdá být OK.

Nebyl to nahodou SYSMAN ?

Nebo ATHelp.

Nedělejte ze mě hlupáka. Zapisování FS struktur (metadat) je něco jiného než hrabání se do vnitřku souboru uživatele (data), přestože ten soubor není otevřen pro zápis, ani není jakýkoli zápis do něj požadován.

Kdyby šlo jen o metadata, tak by se soubory jevily jako poškozené jen na W10, jinde by vše bylo OK (tzn. k poškození by "de facto" nedocházelo). Moje pointa byla, že onen poškozující zápis mohl být výsledkem opravných snah a že tyto snahy (ač v jiné podobě samozřejmě) mohou být přítomny i v dřívejších verzích ovladače. Můj experiment stejně neukazuje, zda-li ko zkopírování šifrovaného souboru je problém jenom ve vynulovaném EFS bitu, nebo zda se třeba nezkopírovala nějaká metadata (třeba nastavení EFS bitu na 1 zároveň značí přítomnost dalších directory entry k danému souboru, které jej nějak blíže popisují (a neviditelnost pro starší verze se řeší stejně jako u LFN).

[Honza]

Další nedouk? Specifikace jasně říká, že se mají bity v Dir_Attr nastavit na nulu a dál na ně nekoukat. Možná to čteme každý jinak, ale mě to připadá celkem jasně jako instrukce nezapisovat tam jedničky. 

Az do okamziku, nez tam ty jednicky zapise Microsoft 

[ByCzech]

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 ?

To samé existuje i ve Windows. Proto např. SW od MS umí startovat rychleji než konkurenčí, umí to totiž využívat něco, o čem ostatní (oficiálně) nevědí a taky neví, kdy se to změní a jak či jak dlouho to bude podporováno, proto to používat je riskantní i když se to doví.

Mezi slušnými lidmi, se tomu nekalokonkureční jednání, zneužívání dominantního postavení ap. Ale to není nic nového pod sluncem, že MS jsou šmejdi.

[ByCzech]

To jsme ale říkali. Děkuji za potvrzení, že implemetace šifrování je špatná i z tohoto pohledu.

No, pokus o čtení šifrovaných souborů na starších verzích Windows (alespoň 8.1) se zdá být OK.

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? To se v 21. století zdá neuvěřitelné. Kdyby to bastalil sousedovic kluk co ještě nevyšel ze základky, tak prosím, ale údajně největší SW firma světa?
Obsah souboru je tak znehodnocen a pokud to je poslední a jediná kopie uživatele, tak stav nepohody uživatele bude přímo úměrný důležitosti obsahu souboru.

Nedělejte ze mě hlupáka. Zapisování FS struktur (metadat) je něco jiného než hrabání se do vnitřku souboru uživatele (data), přestože ten soubor není otevřen pro zápis, ani není jakýkoli zápis do něj požadován.

Kdyby šlo jen o metadata, tak by se soubory jevily jako poškozené jen na W10, jinde by vše bylo OK (tzn. k poškození by "de facto" nedocházelo). Moje pointa byla, že onen poškozující zápis mohl být výsledkem opravných snah a že tyto snahy (ač v jiné podobě samozřejmě) mohou být přítomny i v dřívejších verzích ovladače. Můj experiment stejně neukazuje, zda-li ko zkopírování šifrovaného souboru je problém jenom ve vynulovaném EFS bitu, nebo zda se třeba nezkopírovala nějaká metadata (třeba nastavení EFS bitu na 1 zároveň značí přítomnost dalších directory entry k danému souboru, které jej nějak blíže popisují (a neviditelnost pro starší verze se řeší stejně jako u LFN).

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.

[Reklama]

[ByCzech]

Další nedouk? Specifikace jasně říká, že se mají bity v Dir_Attr nastavit na nulu a dál na ně nekoukat. Možná to čteme každý jinak, ale mě to připadá celkem jasně jako instrukce nezapisovat tam jedničky. 

Az do okamziku, nez tam ty jednicky zapise Microsoft 

Pro MS přece pravidla neplatí. Ty platí pro ostatní. MS si může dělat co chce. A když tam mají být nuly, tak je tam mají mít ostatní, ale MS tak může mít jedničky. A opovažte se někdo udělat nástroj na kontrolu a opravu FS, který by ty bity dle specifikace nuloval, 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

[Lael.Ophir]

To samé existuje i ve Windows. Proto např. SW od MS umí startovat rychleji než konkurenčí, umí to totiž využívat něco, o čem ostatní (oficiálně) nevědí a taky neví, kdy se to změní a jak či jak dlouho to bude podporováno, proto to používat je riskantní i když se to doví.

Tak například LibreOffice startuje velmi pomalu ze dvou důvodů: 1. má velikou konfiguraci v XML (u mě 1.5MB v 59 souborech), která se nějakou dobu parsuje. 2. Má vlastní knihovny pro věci, které ostatní aplikace dělají pomocí systémových knihoven. Například většina aplikací používá COM a OLE, které jsou tím pádem vždy v paměti. LibreOffice si ovšem táhne XPCOM a UNO, které musí natahovat. Podobně je to u řady dalších komponent.
Na Linuxu je k tomu navíc problém s pomalým dynamickým linkováním.

[ByCzech]

To samé existuje i ve Windows. Proto např. SW od MS umí startovat rychleji než konkurenčí, umí to totiž využívat něco, o čem ostatní (oficiálně) nevědí a taky neví, kdy se to změní a jak či jak dlouho to bude podporováno, proto to používat je riskantní i když se to doví.

Tak například LibreOffice startuje velmi pomalu ze dvou důvodů: 1. má velikou konfiguraci v XML (u mě 1.5MB v 59 souborech), která se nějakou dobu parsuje. 2. Má vlastní knihovny pro věci, které ostatní aplikace dělají pomocí systémových knihoven. Například většina aplikací používá COM a OLE, které jsou tím pádem vždy v paměti. LibreOffice si ovšem táhne XPCOM a UNO, které musí natahovat. Podobně je to u řady dalších komponent.
Na Linuxu je k tomu navíc problém s pomalým dynamickým linkováním.

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.

[MD]

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? To se v 21. století zdá neuvěřitelné. Kdyby to bastalil sousedovic kluk co ještě nevyšel ze základky, tak prosím, ale údajně největší SW firma světa?
Obsah souboru je tak znehodnocen a pokud to je poslední a jediná kopie uživatele, tak stav nepohody uživatele bude přímo úměrný důležitosti obsahu souboru.

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.

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.

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.

[Withy14]

...***...

Nadpis tématu je Windows 10 EULA - som zhrozeny. Po 38 stránkach (nečetl jsem to všechno, protože mi to hlava přestal brát) se dočítám něco o instalaci LibreOffice. WTF.

Páni - so jste si to dali, tak chci taky

[ByCzech]

...***...

Nadpis tématu je Windows 10 EULA - som zhrozeny. Po 38 stránkach (nečetl jsem to všechno, protože mi to hlava přestal brát) se dočítám něco o instalaci LibreOffice. WTF.

Páni - so jste si to dali, tak chci taky

Nevím jestli to Lael jen bere nebo i dealuje. Zkuste se zeptat, třeba vám dá vzorek během prvního roku zdarma.

[ByCzech]

...***...

Nadpis tématu je Windows 10 EULA - som zhrozeny. Po 38 stránkach (nečetl jsem to všechno, protože mi to hlava přestal brát) se dočítám něco o instalaci LibreOffice. WTF.

Páni - so jste si to dali, tak chci taky

Nevím jestli to Lael jen bere nebo i dealuje. Zkuste se zeptat, třeba vám dá vzorek během prvního roku zdarma.

Ale jen pokud nebude mít dřív miliardu uživatelů

[ByCzech]

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? To se v 21. století zdá neuvěřitelné. Kdyby to bastalil sousedovic kluk co ještě nevyšel ze základky, tak prosím, ale údajně největší SW firma světa?
Obsah souboru je tak znehodnocen a pokud to je poslední a jediná kopie uživatele, tak stav nepohody uživatele bude přímo úměrný důležitosti obsahu souboru.

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.

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.

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.

Pravda, může to být ještě horší, než dementní pokus o opravu něčeho, není pokažené.

[ByCzech]

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? To se v 21. století zdá neuvěřitelné. Kdyby to bastalil sousedovic kluk co ještě nevyšel ze základky, tak prosím, ale údajně největší SW firma světa?
Obsah souboru je tak znehodnocen a pokud to je poslední a jediná kopie uživatele, tak stav nepohody uživatele bude přímo úměrný důležitosti obsahu souboru.

No pokud to má v metadatech něco tak důležitého, že po ztrátě těchto metadat nebude možné data v případě potřeby dešifrovat, tak to už by bylo ještě horší než nejhorší. Nechtěl bych být v kůži firemního ajťáka, za kterým přijde manager z takhle zkripleným souborem a bude chtít data.
No vlastně dle Laela firemní zákazníci to přivítali a jsou za to rádi. Takže tomu musíme věřit, no ne?

[Honza]

Jardo, ale vždyť ta specifikace platí pořád stejně!

Je to reserved, tj. autor standardu to používá l něčemu v tu chvíli nepopsanému nebo bude k něčemu používat, je tam popsáno jak se k tomu chovat (zapsat při vytvoření nulu, a dál se nestarat). Je tam naprostá forward compatibility. Ti lidé porušili už původní specifikaci, a že jim to chvíli fungovalo neznamená nic. Oni to implementovali bez dopředné kompatibility, ne Microsoft.

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.