[HN Gopher] PeaZip: Open-source file compression and encryption ...
___________________________________________________________________
PeaZip: Open-source file compression and encryption software
Author : thunderbong
Score : 177 points
Date : 2024-05-11 12:19 UTC (10 hours 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!
| 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.
| 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
| 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).
| 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.
| 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.
| 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.
| 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.
| 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 :)
| 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.
| 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.
___________________________________________________________________
(page generated 2024-05-11 23:00 UTC)