Por que o Twitter Bootstrap parece estar criptografado no Windows Explorer?

4

Estou um pouco perplexo, eu corro o Windows 7 Professional N 64-bit e apenas baixei a biblioteca pré-compilada do Twitter Bootstrap de sua homepage.

Na extração, recebi um aviso para fazer backup da chave de criptografia e os arquivos ficaram assim no Windows Explorer:

Eu não uso criptografia nesta máquina, por que isso acontece?

    
por JMK 11.01.2014 / 13:44

1 resposta

3

Eu corri para isso enquanto baixava o Bootstrap esta manhã e pensei que poderia ter pegado alguns malwares ...

De acordo com este problema do github , é porque o arquivo zip foi criado em um Mac.

Esta postagem no blog descreve o problema:

It’s kind of funny really. The ZIP specification mandates that a program/OS creating a zip archive include a tag informing about itself to the program trying to decompress the archive. This information is called “version made by”, and looks like this:

      0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
      1 - Amiga                     2 - OpenVMS
      3 - UNIX                      4 - VM/CMS
      5 - Atari ST                  6 - OS/2 H.P.F.S.
      7 - Macintosh                 8 - Z-System
      9 - CP/M                     10 - Windows NTFS
     11 - MVS (OS/390 - Z/OS)      12 - VSE
     13 - Acorn Risc               14 - VFAT
     15 - alternate MVS            16 - BeOS
     17 - Tandem                   18 - OS/400
     19 - OS/X (Darwin)            20 thru 255 - unused

Now, interestingly, it seems that Mac OS is tagging the zip archives it creates with the value 3 (UNIX). Ok, so far no problem, I guess.

The problem happens when Windows gets confused about how to interpret file/folder attributes. In FAT/NTFS, these values are stored according to this definition of File Attribute Constants. You’ll see that FILE_ATTRIBUTE_ENCRYPTED has a value of 0x4000.

The interesting part is how Mac OS is storing its file attributes in the zip archive. Mac OS, being a UNIX based OS, uses the UNIX file/folder attributes system (and permissions, but that’s a topic for another time…).. Well, it just so happens that in POSIX, the flag to describe a directory/folder (S_IFDIR) coincidentally also has the value 0x4000. So it turns out the zip decompression code wasn’t aware that there might be other operating systems out there that might create zip archives…

Can you change this behavior?

No, but you can clear the encryption flag from the extracted files/folders easily.

    
por 30.12.2014 / 17:52