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

[phoronix]

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

While FreeBSD 13 is the current stable version of this leading open-source BSD operating system, FreeBSD 12.3 shipped today for their N-1 series...

https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-12.3

[kvuj]

Oh yeah, they maintain their own unzip utility right? That's pretty cool.

What Linux distros are using is an ancient, unmaintained version (2009) with a bunch of distro patches on top. I think I also remember a couple of security vulnerabilities being present in it, but don't quote me on that.

EDIT: It seems they are using NetBSD's utility and are often syncing with it (https://github.com/freebsd/freebsd-s.../unzip/unzip.c).

EDIT2: Freebsd's version is 1133 lines while the one used by Arch is 82057 lines

Counted with:

find -type f -name '*.[ch]' -exec cat {} + | grep -c '^'

[Anux]

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?

[klapaucius]

You could have used tokei

[Old Grouch]

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/questions/35818/are-password-protected-zip-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/encrypting-decrypting-7zip

[skeevy420]

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

[skeevy420]

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.

[kylew77]

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.

[Anux]

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.

[kvuj]

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.)