Occasionally spews thoughts at https://tclish.org/
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:…
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…
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:…
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…