It's just nobody usually implements a limit during decompression because people aren't usually giving you zip bombs. And sometimes you really do want to decompress ginormous files, so limits aren't built in by default.

Your given language might not make it easy to do, but you should pretty much always be able to hack something together using file streams. It's just an extra step is all.

It's intuitively extremely strange to me!

Even ignoring how zips work: Memory needs to be allocated in chunks. So before allocating a chunk, you can check if the new memory use will be over a threshold. CPU is used by the program instructions you control, so you can put checks at significant points in your program to see if it hit a threshold. Or you can have a thread you kill after a certain amount of time.

But the way zips do work makes it a lot simpler: Fundamentally it's "output X raw bytes, then repeat Y bytes from location Z" over and over. Abort if those numbers get too big.

cgroups with hard-limits will let the external tool's process crash without taking down the script or system along with it.

In a practical sense, how's that different from creating a N-byte partition and letting the OS return ENOSPC to you?

    import zipfile
    with zipfile.ZipFile("zipbomb.zip") as zip:
        for name in zip.namelist():
            print("working on " + name)
            left = 1000000
            with open("dest_" + name, "wb") as fdest, zip.open(name) as fsrc:
                while True:
                    block = fsrc.read(1000)
                    if len(block) == 0:
                        break
                    fdest.write(block)
                    left -= len(block)
                    if left <= 0:
                        print("too much data!")
                        break