Announcement

Collapse
No announcement yet.

FreeBSD 12.3 Released With Updated AMD & Networking Hardware, Password Protected ZIPs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • KesZerda
    replied
    Originally posted by kvuj View Post

    Code:
    size /usr/bin/unzip
    gets me 27424 Bytes so 27 KB, but
    Code:
    ls -lh
    gets me 22k

    Probably some bss parts not being shown with size since it looks at how much RAM it takes to load it.

    Pretty damn smaller it seems, but realistically it's probably not the end of the world haha.
    Keep in mind that unzip under FreeBSD uses libarchive under the hood, so a lot of the functionality is in shared libraries, and won't be reflected in the file sizes. In fact, because FreeBSD tar also uses libarchive, you can use tar to uncompress and create zip files without needing the unzip binary at all.

    Leave a comment:


  • kvuj
    replied
    Originally posted by Anux View Post

    It really supports everything out there hu? I just took a look at the binary size in my Arch Linux AMD64 install, its 170kb. How big is the FreeBSD version @kvuj ?
    Code:
    size /usr/bin/unzip
    gets me 27424 Bytes so 27 KB, but
    Code:
    ls -lh
    gets me 22k

    Probably some bss parts not being shown with size since it looks at how much RAM it takes to load it.

    Pretty damn smaller it seems, but realistically it's probably not the end of the world haha.

    Leave a comment:


  • Anux
    replied
    Originally posted by kvuj View Post

    To be fair, most of those lines seems to come from specific OS folders (Atari, AmigaOS, BeOS, theos, etc.)
    It really supports everything out there hu? I just took a look at the binary size in my Arch Linux AMD64 install, its 170kb. How big is the FreeBSD version @kvuj ?

    Leave a comment:


  • kvuj
    replied
    Originally posted by Anux View Post

    But still 79000 LOC just for crossplatform? Do they have a seperate assembly implementation for every CPU-variation out there? C alone is already cross platform and since its a CLI there shouldn't be to much difference for any *nix platform. That would leave DOS/Windows CLI which also shouldn't need that much code.

    Guess i'll have a look at the code on the weekend. Really interested in why.
    To be fair, most of those lines seems to come from specific OS folders (Atari, AmigaOS, BeOS, theos, etc.)

    Leave a comment:


  • Anux
    replied
    Originally posted by skeevy420 View Post

    The one on Arch is crossplatform and has been around since the DOS era. I imagine if the FreeBSD one had decades of crossplatform complexity it'd be a bit larger.
    But still 79000 LOC just for crossplatform? Do they have a seperate assembly implementation for every CPU-variation out there? C alone is already cross platform and since its a CLI there shouldn't be to much difference for any *nix platform. That would leave DOS/Windows CLI which also shouldn't need that much code.

    Guess i'll have a look at the code on the weekend. Really interested in why.

    Leave a comment:


  • kylew77
    replied
    FreeBSD used to be my most favorite Unix, until I started reading more and more about its security and now I'm not so sure it is the best. FreeBSD doesn't have ASLR by default nor position independent executables. There is hardened BSD but it has a bus factor of 2 meaning there are two developers and if they get hit by a bus or decide to quit then the project is done. I really like OpenBSD for security but it is lacking in areas like a working linux emulator or virtualization like FreeBSD. FreeBSD 14 should have more security features enabled by default but we have just barely started on 13.x series so 14.0 is a long time away.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by Anux View Post
    This seems to be a little strange. Maybe the BSD version has more dependencies than the linux version?
    On the contrary, ZIP ain't that complex and might well be doable with 1000 lines of C code. Maybe the linux version is faster or uses less memory?
    The one on Arch is crossplatform and has been around since the DOS era. I imagine if the FreeBSD one had decades of crossplatform complexity it'd be a bit larger.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by Old Grouch View Post
    Password protected zip files do not encrypt the file names, which can leak information, and when I last looked, did not have integrity checking of the list of filenames in the archive, so it is possible for a malicious actor to replace an encrypted file in the archive with non-encrypted file of the same name. A workaround is to put your files in a non-encrypted zip archive, then put the single file that is the zip archive into an encrypted zip archive (double zipping).
    Back in the day I remember pirates using that exploit by putting the password in the archive as a file name.
    1. game.exe
    2. game.dll
    3. Password is "12345678".txt

    Leave a comment:


  • Old Grouch
    replied
    Password protected zip files do not encrypt the file names, which can leak information, and when I last looked, did not have integrity checking of the list of filenames in the archive, so it is possible for a malicious actor to replace an encrypted file in the archive with non-encrypted file of the same name. A workaround is to put your files in a non-encrypted zip archive, then put the single file that is the zip archive into an encrypted zip archive (double zipping).

    https://security.stackexchange.com/q...p-files-secure

    Alternatively 7-zip allows for encrypted archives/containers which are encrypted such that the list of files is encrypted, so you have to provide the password/passphrase to open the archive/container to get a listing of the files in the archive/container.

    https://www.redhat.com/sysadmin/encr...ecrypting-7zip

    Leave a comment:


  • klapaucius
    replied
    You could have used tokei

    Leave a comment:

Working...
X