[HN Gopher] PeaZip: Open-source file compression and encryption ...
       ___________________________________________________________________
        
       PeaZip: Open-source file compression and encryption software
        
       Author : thunderbong
       Score  : 324 points
       Date   : 2024-05-11 12:19 UTC (1 days ago)
        
 (HTM) web link (peazip.github.io)
 (TXT) w3m dump (peazip.github.io)
        
       | theandrewbailey wrote:
       | I've been using this for over a decade. I keep using it because
       | it extracts files directly where you want them, instead of
       | extracting to a temp folder, then copying to where you want,
       | multiplying IO traffic by up to 2. It also lets me use 7z files
       | with zstd compression, though I'm not sure which other software
       | supports it.
        
         | shawnz wrote:
         | Moving files from one directory to another directory on the
         | same filesystem doesn't actually result in any data getting
         | moved, only the directory entries are changed
        
           | iwwr wrote:
           | In some restricted environments (e.g. containers in CI, build
           | servers or AWS Lambda) you may have limited disk space or no
           | write access at all, so it is useful to have a tool that can
           | stream to memory while decompressing on the fly, and
           | discarding what you don't need.
        
           | maccard wrote:
           | You've made a big assumption about being on the same file
           | system there. We had a CI job that was spending an awful lot
           | of time in fetching cached artifacts.
           | 
           | We investigated and it turns out that CI was pulling to
           | %TMP%, but we were actual executing the builds on a separate
           | EBS volume meaning we downloaded and wrote to an EBS volume,
           | then had to copy it to another remote volume, it was super
           | easy to spot on windows, but I'm not sure I would have
           | twigged it as easily if we were moving from /tmp to
           | /data/dira
        
             | shawnz wrote:
             | Sure, but you're probably not using PeaZip (which is
             | primarily a GUI front-end for existing compression tools)
             | in CI or containerized environments. For those situations
             | there are specialized tools which are more appropriate.
        
               | maccard wrote:
               | I'm not in this case, but if something writes to /tmp and
               | then copies it to /data, there is no guarantee that they
               | are on the same device or even network.
        
           | bravetraveler wrote:
           | Let's start slicing the pie, everyone.
           | 
           | On Linux this is becoming a rarity; _' /tmp' (the usual
           | $TMPDIR)_ is mounted using _tmpfs_ , a distinct memory-backed
           | filesystem. Windows on the other hand is happy for this to
           | reside on your physical disk, persistently. I think - this
           | isn't my area.
           | 
           | This almost guarantees your _" yes, but"_ doesn't apply for
           | anyone using Fedora Linux, for example. I dare say nearly any
           | distribution that includes systemd, and
           | probably/consequently, _' tmp.mount'._
           | 
           | While it _is_ memory backed, one can only copy /read from
           | this as fast as the destination can _write_.
        
             | edflsafoiewq wrote:
             | You shouldn't use /tmp for that for that reason. aunpack
             | for example extracts into a temp directory in the same
             | directory as the final destination.
        
               | bravetraveler wrote:
               | I'm fine with either, I think you and Andrew at the top
               | of the thread agree - PeaZip does as you suggest.
               | 
               | I'm just piling on :D Things that naively use temporary
               | directories otherwise may run into an extra copy...
               | because it's not necessarily on the same filesystem. It's
               | rare, in fact, on modern Linux
        
             | dataflow wrote:
             | /tmp is often _not_ tmpfs, in fact.  /dev/shm or /var/run
             | are.
        
               | bravetraveler wrote:
               | Yes, and? It still is very common to find. Turns out
               | things aren't homogeneous. People often both die forever-
               | alone and happily married, too.
               | 
               | I already said it's up to the distribution. I wasn't
               | really interested in splitting it more than I have, I
               | hoped to avoid it... but let's go. It's been upstream
               | over a decade
               | 
               | https://github.com/systemd/systemd/commits/main/units/tmp
               | .mo...
               | 
               | Participation, as always, has been/remains optional.
               | Anything using 'systemd' will likely have this be
               | 'tmpfs', unless _' ConditionPathIsSymbolicLink'_ is
               | violated.
               | 
               | Anything _not_ using _' systemd'_ is a niche that most of
               | the industry ignores. See how uninsightful/unhelpful
               | these statements are?
               | 
               | More specifically, this leaves the one
               | directive/condition to consider... and a subset of a
               | subset that's relevant - systems using runit/s6/whatever.
               | 
               | Anyway, that's the fun thing about _' often'_. It both
               | often is and isn't. Put simply, word games.
               | 
               | We're both right, _' /tmp'_ often is _and_ isn 't
               | 'tmpfs'. It's an implementation detail. It's codified
               | into some standards, and it turns out some distributions
               | are more prepared/cognizant than others.
               | 
               | The inconsistency in applying this makes the assertion
               | that lead to this whole thread off base.
               | 
               |  _edit:_ I originally mistook the last edit two years ago
               | for the creation time - adjusted. This has been
               | established for ~14 years!
        
               | dataflow wrote:
               | > Anything _not_ using  ' _systemd_ ' is a niche that
               | most of the industry ignores. See how
               | uninsightful/unhelpful these statements are?
               | 
               | Ubuntu uses systemd. And yet it doesn't use tmpfs for
               | /tmp. I literally just even installed 24.04 right now
               | (new LTS from 3 weeks ago!) _just_ to verify this hadn 't
               | somehow changed since the last time I had checked, and it
               | still hadn't.
               | 
               | I'm not here to argue or play word games, I was just
               | trying to point out that this isn't some kind of niche
               | setup. The way you make it sound when you talk about
               | Fedora or s6 or whatever gives readers the impression
               | that they can assume /tmp is on tmpfs on anything
               | mainstream & modern, but that's simply not the case --
               | it's not the case on _the second(?) most popular distro_.
               | 
               | That's all I was trying to convey.
        
         | baal80spam wrote:
         | The trick to do it using the default 7zip file manager is to
         | open the .7z file in the manager (double clicking it, not right
         | clicking it), and extract the archive whenever you want it - it
         | will be extracted straight there with no transition using
         | temporary folder.
        
         | Adj_and_Styles wrote:
         | The atool script is just a wrapper around many compression
         | tools. Try atool -x which creates the temp folder under final
         | destination.
         | 
         | https://www.nongnu.org/atool/
         | 
         | Edit: just noticed it was mentioned in other reply, but as
         | aunpack, a symlink to atool. I got used to the -x|-l|-a|...
         | style and rarely remember the alternative names.
        
       | causality0 wrote:
       | Can anyone explain why this is better than 7zip?
        
         | jsheard wrote:
         | 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.
        
           | lobito14 wrote:
           | Can you please provide the source of this thread?
        
             | tylerritchie wrote:
             | https://landave.io/2018/01/7-zip-multiple-memory-
             | corruptions...
             | 
             | but also see: https://news.ycombinator.com/item?id=16986377
        
           | soraminazuki wrote:
           | 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
           | 
           | https://peazip.github.io/peazip-sources.html
           | 
           | 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.
           | 
           | https://libarchive.org
        
             | jsheard wrote:
             | The native archive support that was recently added to
             | Windows itself is backed by libarchive.
        
               | marwis wrote:
               | Doesn't streaming architecture of libarchive make it a
               | poor choice for working with random access archives?
        
         | canistel wrote:
         | Cross-platform - works on Linux (with GUI).
        
         | eviks wrote:
         | Zstd support and x-platform
        
           | delfinom wrote:
           | 7zip 24 supports Zstd
        
         | Sakos wrote:
         | 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.
        
         | ementally wrote:
         | MOTW support enabled by default
         | https://github.com/nmantani/archiver-MOTW-support-comparison...
        
         | tux21b wrote:
         | 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.
        
           | chungy wrote:
           | 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.
        
             | fallingsquirrel wrote:
             | That's concerning. What if your archive password is ;rm -rf
             | --no-preserve-root /? There might be an easy CVE for the
             | taking here.
        
         | Tijdreiziger wrote:
         | Prettier UI (IMHO)
        
       | sneak wrote:
       | > _Offer two factor authentication (password + keyfile) for all
       | formats supporting encryption, to increase security against
       | guessing and dictionary based attacks on weak passwords._
       | 
       | uhhh, that's not how symmetric encryption works. We have salted
       | password-based (PB) KDFs for exactly this purpose.
       | 
       | Encryption probably doesn't belong in the compression container
       | format.
        
         | Retr0id wrote:
         | PeaZip also uses a PBKDF (PBKDF2). No longer the latest and
         | greatest, but _fine_.
        
           | lucb1e wrote:
           | I guess I agree with calling PBKDF2 _fine_ , but it may be
           | good to know the caveats:
           | 
           | - Just because it says it uses PBKDF2 doesn't mean it is
           | strong. The strength fully depends on the number of rounds it
           | uses, and especially in legacy (>10 years old) software I see
           | it a lot that some amount of rounds are hardcoded which can
           | now be computed in a few milliseconds on a CPU
           | 
           | - PBKDF2 gives the attacker a ~1000x speedup. If your CPU
           | spends 2 seconds on computing the hash every time, an
           | attacker with a run-of-the-mill GPU spends 2 milliseconds per
           | guess (500 guesses per second). Using something like Bcrypt
           | or Argon2, that speedup gets to iirc "only" 12x (so if you
           | spend 2 seconds, the attacker spends ~170 milliseconds or 6
           | guesses per second). Iirc this speedup is due to GPU RAM
           | being faster than the main RAM. So while PBKDF2 isn't great,
           | it's also not like it's broken: this has been a known
           | property since forever and it's still orders of magnitude
           | better than a plain hash
        
         | lucb1e wrote:
         | The quote is correct. It does not say they're not using a KDF
         | or salting, which you seem to read into it? The keyfile is the
         | "something you have" and the password "something you know", so
         | two-factor checks out, even if it's not a time-based token that
         | people expect nowadays (though TOTP is essentially the same but
         | on another device, extracting time-based short codes from the
         | long key to make it convenient to type over). No matter how
         | good your KDF, a weak or reused password can still be
         | crackable, so a key file can make sense even if you use a
         | salted KDF
        
           | sneak wrote:
           | How is this different from just a keyfile?
        
             | gkbrk wrote:
             | Someone with the keyfile but without the password cannot
             | decrypt?
        
               | sneak wrote:
               | Do people usually store key material without encryption
               | at rest?
               | 
               | You're not writing the naked bytes of the key directly in
               | a file.
               | 
               | Anyway, authentication refers to communication between
               | systems. That's not what this is. Decryption is not
               | authentication (except perhaps of the decrypted
               | plaintext, which is not what we are discussing).
        
               | rakoo wrote:
               | > Do people usually store key material without encryption
               | at rest?
               | 
               | As usual, depending on the threat model, yes, it can be
               | very valid to store key material on a disk without
               | encryption. Not everyone is Snowden.
        
       | c0l0 wrote:
       | PeaZip is great software, and doubly so because it is written
       | using Lazarus and compiled with Free Pascal. I highly recommend
       | giving it a try, if only to experience that high quality software
       | can be built using tools that lead you somewhat off the beaten
       | path.
       | 
       | Unfortunately, its lead developer has recently posted[0] that he
       | has to undergo what seems to be complicated, major eye surgery,
       | and that he will probably be unable to continue development :(
       | 
       | [0]:
       | https://old.reddit.com/r/PeaZip/comments/1bn7pu0/communicati...
        
         | stefanos82 wrote:
         | Seems like he's doing OK, thank goodness!
         | https://old.reddit.com/r/PeaZip/comments/1cpdvum/peazip_980_...
        
           | cxr wrote:
           | Neither the existence of this link nor anything in it
           | contradicts the developer's earlier post. It looks like the
           | situation was inaccurately summarized by the HN user with the
           | top comment here--the PeaZip developer didn't announce that
           | he or she was going to stop working on PeaZip.
        
           | parhamn wrote:
           | > Drag & drop from app to system is certainly a mayor
           | usability boost, but it is not simple to implement as it
           | requires a dedicated solution for each supported OS and
           | desktop environment.
           | 
           | Off topic, but this is why many devs choose electron.
        
             | NavinF wrote:
             | > and desktop environment
             | 
             | Off topic, but this is why many devs choose not to support
             | Linux. Every distro is its own special snowflake
        
               | patrickaljord wrote:
               | > Off topic, but this is why many devs choose not to
               | support Linux. Every distro is its own special snowflake
               | 
               | most DE use the same standards (dbus etc) so no
        
               | arp242 wrote:
               | That's just not true; I've been using the relatively
               | obscure Void Linux for almost 10 years, and rarely have
               | distro-specific issues, including with Linux-native games
               | from gog.com. Nor do people report distro-specific issues
               | in software I develop on Void.
               | 
               | And it's doubly not true for something like drag-and-
               | drop, which exists on the Desktop Environment level
               | rather than distro level.
        
         | bozey07 wrote:
         | I like seeing software written in Free Pascal, they tend to be
         | small and performant. Cheat Engine[0] is another example.
         | 
         | [0] https://github.com/cheat-engine/cheat-engine
        
           | r-w wrote:
           | I searched around and found this tutorial[0] on the official
           | wiki. Seems like a decent intro to the history & syntax of
           | the language. There's also another tutorial[1] on the more
           | modern iteration of the language, as well as some video
           | tutorials[2] on using the IDE for GUI development.
           | 
           | [0]: https://wiki.freepascal.org/Basic_Pascal_Tutorial/Introd
           | ucti...
           | 
           | [1]: https://castle-engine.io/modern_pascal
           | 
           | [2]: https://wiki.freepascal.org/Lazarus_videos
        
         | MaxBarraclough wrote:
         | Somewhat related: _GID_ (for _Generic Image Decoder_ ) is
         | written in Ada and significantly outperforms ImageMagick
         | (written in C) in some benchmarks.
         | 
         | https://gautiersblog.blogspot.com/2024/03/benchmarking-gener...
        
         | deaddodo wrote:
         | Yeah, PeaZip is the best example of what Lazarus is capable of,
         | if you feel like using it.
         | 
         | I remember back in my Pascal-loving days, especially after the
         | .NET release of VB, looking at PeaZip+Lazarus and being
         | inspired.
        
         | zoom6628 wrote:
         | +100 for Lazarus and FreePascal
        
       | Dwedit wrote:
       | Programs like 7-zip and PeaZip both have an unusual feature:
       | Ability to explore NT paths that Windows Explorer will refuse to
       | load.
       | 
       | You can go to a path like "\\\?\Harddisk0Partition2\" in 7-zip
       | file manager or PeaZip. On my PC, that happens to be the EFI
       | partition. (Need to run as Admin before it lets you access the
       | EFI partition)
       | 
       | Sysinternals WinObj will let you see all the paths in the NT
       | Object Namespace. To convert an NT Object Namespace path into a
       | standard Windows path, put "\\\?\GLOBALROOT\" at the beginning of
       | the path. Windows Explorer and the File Dialogs will refuse to
       | open such paths, but many Win32 applications will accept those
       | paths as command line arguments.
        
         | supriyo-biswas wrote:
         | TIL, thanks!
         | 
         | To add to this list of unusual features, 7-zip can also parse
         | many self-extracting PE executables and display the executable
         | sections of ELFs and PEs. I'm not sure if this has been
         | documented anywhere, though.
        
           | Dwedit wrote:
           | 7-zip version 15.05 will also decompile NSIS scripts
           | (Nullsoft Installation System), but the feature was taken out
           | of newer versions.
        
             | ddtaylor wrote:
             | Why was the feature removed?
        
               | Dwedit wrote:
               | Presumably due to code maintenance issues, they couldn't
               | ensure the installer script decompiler was secure. File
               | extraction from NSIS is still there, just not installer
               | script decompilation.
        
         | panzi wrote:
         | Reminds me of when I used WinZip to copy files from a shared
         | directory that had non-ASCII (non latin even!) characters in
         | the file names over 20 years ago. Windows Explorer refused to
         | do it. Can't remember the error message, WinZip did the job.
        
           | NetOpWibby wrote:
           | To this day I still don't put special characters in my file
           | names. I've been on macOS for years but who knows if I'll
           | need a Windows machine?
        
         | chungy wrote:
         | Not so much "refuse", but lacking code to go down those paths.
         | ReactOS includes built-in shell extensions to browse native NT
         | device paths and the registry right in Explorer. Its same shell
         | extensions can even be installed on Windows to achieve the same
         | thing in Microsoft's Windows Explorer :)
        
         | jasomill wrote:
         | Interesting.
         | 
         | Also note that, while File Explorer and Windows file/open
         | dialog boxes don't accept "\\\?"-style paths at all, you can
         | use the "Run" command (Windows Key+R or choose "Run" from the
         | Start Menu) to open any available (connected and online) volume
         | in File Explorer using a path of the form
         | "\\\?\Volume{UUID}\"[1], even if it hasn't been assigned a
         | drive letter or mount point.
         | 
         | Note that, if UAC is enabled, this won't work for EFI system
         | partitions unless you're running Explorer elevated, which can
         | be tricky. You used to be able to kill the explorer.exe process
         | and start a new one from an elevated command prompt or Task
         | Manager, but this no longer works in Windows 11 (Explorer
         | starts, but not elevated).
         | 
         | [1] For GPT disks, this UUID is the GPT partition's unique ID.
         | 
         | I have no idea how the ID is calculated for non-GPT disks,
         | though I have noticed a few interesting properties:
         | 
         | * For volumes on MBR-partitioned disks, all but the first eight
         | bytes of the UUID are zero.
         | 
         | * The UUID is not obviously related to a FAT filesystem's
         | serial number.
         | 
         | * UUIDs are assigned to devices with removable media like
         | optical drives and SD card readers even when empty, and do not
         | change when media is inserted or removed.
         | 
         | In any case, the easiest way I know of find this is using
         | PowerShell: use "Get-Disk" to find the disk number (and if this
         | doesn't give you enough information to identify the correct
         | disk, use "Get-Disk | Format-List" for more information), "Get-
         | Partition -DiskNumber _n_ " to find the partition number (if
         | the disk is partitioned), and, finally, "Get-Partition
         | -DiskNumber _n_ -PartitionNumber _m_ | Get-Volume | select Path
         | " to get the desired path.
         | 
         | In the case of non-hard disk devices like optical drives, "Get-
         | Disk" and/or "Get-Partition" may not be available, so use "Get-
         | Disk | Format-List" for detailed information on all available
         | volumes, including all volume paths and, hopefully, enough
         | additional information to identify the volume you want.
         | 
         | You can also find volume paths with WinObj or the fsutil
         | command, but PowerShell provides more useful information to
         | help identify the correct volume.
        
       | Qem wrote:
       | Currently using it under Linux because it's able to extract the
       | malformed large zip files generated by onedrive, that give a
       | corrupted file error when you try to open them using the native
       | file extractor. See https://www.bitsgalore.org/2020/03/11/does-
       | microsoft-onedriv...
        
       | bobbob1921 wrote:
       | LOVE peaZip! What I especially like about it is in my experience
       | it's been very portable on linux, and the gui has always been
       | portable as well. (it works on Tails - so it's great for putting
       | onto a USB stick that contains encrypted zip / veracrypt archives
       | for when you need to access those on an air gap d machine.)
        
       | aquova wrote:
       | I've been using Ark on Linux for some time now, but have always
       | heard people sing PeaZip's praises, curious if anyone has any
       | experience or preference between the two.
        
       | tahoeskibum wrote:
       | Can't wait to see an irreverent logo
        
       | exposition wrote:
       | There's also pzip[1], which lets you create zip files and extract
       | them in parallel.
       | 
       | [1] https://github.com/ybirader/pzip
       | 
       | Disclaimer: I'm the author
        
       | synergy20 wrote:
       | how is the GUI done for cross platform? not familiar with Pascal
       | ecosystem
        
         | gattilorenz wrote:
         | Lazarus/FreePascal compile to a native binary for more
         | platforms than you will realistically need
        
       | seam_carver wrote:
       | If your needs are basic I just use tar. It's built into macOS and
       | Windows 10. It even supports rar!
        
       | hgyjnbdet wrote:
       | Genuine question: why would I use this over 7zip?
        
         | UberFly wrote:
         | No reason to if you like 7zip. They all do the same thing just
         | look different for the most part.
        
         | ies7 wrote:
         | I really don't remember well, long long time ago in Window
         | (XP?) either you can select multiple folders and zip each of
         | them separately and/or you can select multiple zip files and
         | extract them to separate folders within a single context menu
        
         | pennybanks wrote:
         | doesnt windows now have all the similar tools default?
        
           | marwis wrote:
           | The feature built into windows (even after recent update) is
           | a lot slower
        
         | recursive wrote:
         | Why use 7zip over this?
        
       | jojohohanon wrote:
       | It blends the CLI by incorporating scripting engine?! That's not
       | what mean by cli friendly.
        
       | user20180120 wrote:
       | Can it do lrzip?
       | 
       | Did a quickish search
       | 
       | https://github.com/nakijun/peazip/issues/149
        
       | teo_zero wrote:
       | The fact that GTK3 is considered the new thing still in alpha is
       | a red flag for me.
        
       | croemer wrote:
       | Nitpicks:
       | 
       | 1. Command to unquarantine in docs is wrong. It should be `xattr
       | -d com.apple.quarantine /Applications/peazip.app` not `xattr -dr
       | com.apple.quarantine /Applications/peazip.app`
       | 
       | 2. Not available via homebrew
       | 
       | 3. Can't open issues, neither on Github nor sourceforge
        
         | someonehere wrote:
         | 1. Right click on the app and choose open. When prompted, click
         | open 2. https://github.com/rogeriopradoj/homebrew-cask-
         | peazip/blob/m...
        
         | sigzero wrote:
         | There is noting wrong and it is probably better to use 'xattr
         | -d -r' since an .app file is just a directory structure.
        
       | lucifer153 wrote:
       | I was surprised that the software was written in Pascal which is
       | the dead language
        
       ___________________________________________________________________
       (page generated 2024-05-12 23:02 UTC)