lexfiend

Possibly because:

> The machine I am using is MacBook Pro, 2019 (2.4 GHz Quad Core i5, 8GB, 256GB SSD, Big Sur 11.1)

Given the target schema, 100M rows with only 8GB RAM risks hitting swap hard.

25 years ago, junior sysadmin me had to restore our server's drives from tape. To my horror, all the backup tapes were corrupted. It took a while to figure out what happened; my 2am cron job script basically did this:

  run_backup & eject_tape

Fortunately, we were able to reconstruct the server's contents from individual workstations, but I had to endure "how's the backup?" ribbing for many months.

I also changed the script to:

  run_backup && test_backup && eject_tape

so if the tape was still in the drive when I got in to work, I knew to check on things.

The simplest mitigation probably bears mentioning: Prepend all wildcarded relative paths with `./`, because `rm ./*` does what you'd expect.

> This "vulnerability" doesn't even need to involve a shell at all - any exec*() with the same arguments will have the same result.

Wildcard expansions are done by shells, so no, exec() wouldn't trigger this "vulnerability".

Unless you're talking about a specific language's exec() that either does its own wildcard expansion, or actually runs its arguments in a shell.