michalc

You could even say you never knew what you were… MISSING ;-)

Agreed!

There’s a bit of an assumption that the branching _has_ to exist, but so often it doesn’t.

To be fair, the article does suggest other techniques: hinting at separating pure/impure code for example, which I would say often results in a “net” cyclomatic complexity reduction. But I would disagree with “extract method” as the most effective… yes very effective in reducing cyclomatic complexity, but that ignores downsides, especially if the code needs to be thought about as a whole.

I’ve been liking keeping sensitive config outside of the repo directory altogether, and instead putting it into a dotted folder in my home directory, so something like

~/.project-name/local.env

And then referring to that location in the repo, say from a docker compose file.

Works well so far

I would say it's only really a burden if you fight it, or don't expect to have to do it and right at the end someone asks "er... does this work without JavaScript?". My attitude is that it's a combination of freeing and a challenge: "we can and should make it simple, even boring"

Automatic enforcement for all services is tricky, because you _can_ depend on JavaScript if the user needs justify it.

> the rest will soon follow

If you’re looking for requests ;-), I would love an ECS (and specifically Fargate) emulator that actually ran Docker containers locally as though they were in ECS

Submitted to Unicode yesterday (so please be gentle!)

I think I can understand why this wasn’t addressed for so long: in the vast majority of cases if your db is exposed on a network level to untrusted sources, then you probably have far bigger problems?

So my definition of big data was data so big it cannot be processed on a single machine in a reasonable amount of time.

I guess they’re using a different definition?

Short answer is no, not as far as I am aware/can reason about it

In more detail: so by my understanding there are two techniques in making zip bombs…

Firstly nested ZIPs that leverage the fact that some unZIP programs recursively extract member files. stream-unzip doesn’t do this (Although you could probably use stream-unzip as a component in a vulnerable recursive ZIP parser if you really wanted to… but that I would argue is not the responsibility of stream-unzip)

The second technique is overlapping member files, but this depends on them overlapping as defined by the central directory at the end of the ZIP, which stream-unzip does not use

But if you are accepting files from an untrusted source, then you should validate the size of the uncompressed data as you unZIP (which you can do as you validate along with any other properties of the data)