I don't know if this is better, but 7zips developer has an unnerving track record when it comes to security practices. He resisted adopting basic mitigations like DEP and ASLR for a long time, only relenting after a security researcher basically begged him to after finding arbitrary code execution exploits, and he still doesn't want to use any more advanced hardening techniques because they (slightly) bloat the binary size or have a (tiny) performance overhead.
I'm all for lean software but breaking ASLR by stripping the relocation tables, just to shave a few kilobytes off an executable which is primarily intended to parse untrusted files is just reckless.
PeaZip appears to rely on 7zip for most of its supported formats. So Peazip isn't really an alternative if you want to avoid 7zip out of security concerns.
> 7z ... should be placed in (peazip)/res/bin/7z, to manage 7Z files and most of the other supported formats
I personally like libarchive and its bsdtar CLI, which also supports a wide range of formats. I don't know if there's any popular GUI frontend for it though.
I've sworn by 7zip since forever and I still use it primarily, but I'd recommend peazip to anybody who wants 7zip but with a better, more convenient GUI (and workflow/behavior). I still think about switching back to peazip (only used it for a few months), but old habits die hard.
I hate that PeaZip does not support passwords with a quotation mark (") in the UI. I haven't reviewed the code, but I am assuming that they are neither passing the password via a variable (linked library) nor via an execve call (less secure), but via some sub-shell which is a common attack vector and bad security practice. But as I said, I haven't reviewed the code.
I haven't ran nor looked at the code for PeaZip, but the website describes the program as a GUI wrapper around command line utilities. I highly suspect it's the sub-shell thing.
