Changes between Initial Version and Version 2 of Ticket #321
- Timestamp:
- Apr 23, 2021, 2:44:50 PM (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #321
- Property Keywords opinionated added; opionated removed
- Property Summary changed from Switch static-cat to a blacklist instead of whitelist to Switch static-cat to a denylist instead of allowlist
-
Ticket #321 – Description
initial v2 1 Currently, static-cat (and related infrastructure) has a list of extensions that it will read (see [http://scripts.mit.edu/faq/50/]). Any other extension it will refuse to handle. We should switch from whitelisting certain "safe" extensions (and incrementally increasing that list) to blacklisting certain "dangerous" extensions (and possibly incrementally increasing that list).1 Currently, static-cat (and related infrastructure) has a list of extensions that it will read (see [http://scripts.mit.edu/faq/50/]). Any other extension it will refuse to handle. We should switch from allowlisting certain "safe" extensions (and incrementally increasing that list) to denylisting certain "dangerous" extensions (and possibly incrementally increasing that list). 2 2 3 3 (N.B.: If you want a fun ticket to spend five hours discussing before you fail to reach a concensus on the desirability of doing it, here's a great one.) … … 9 9 At the moment, if somebody decides to put, say, secret-info.rtf, secrets.txt.gz, secrets.txt.bz2, secrets.json, secrets.yaml, secrets.sql, or presumably some huge number of other extensions in their locker, they might verify that loading them didn't work, and conclude that they're safely protected. As is, however, at some point in the indefinite future, a request from another scripts user may result in us unblocking any of those extensions (with variable amounts of angst about the security implications of doing so). 10 10 11 Our original user would have no particular reason to expect their files to have suddenly become accessible. Using a blacklist would help protect against this --- as long as we never remove things from the blacklist, a user who checks once can be reasonably assured that their files will never become visible.11 Our original user would have no particular reason to expect their files to have suddenly become accessible. Using a denylist would help protect against this --- as long as we never remove things from the denylist, a user who checks once can be reasonably assured that their files will never become visible. 12 12 13 13 Naturally, the reverse of this is that a user who checks once is ''not'' reasonably assured that a page will remain visible. Fortunately, site breakage tends to be fairly obvious, and a scripts.mit.edu user is liable to notice (or get an email from a user) if part of their (actively used) site spontaneously breaks, at which point they can fix it. The reverse does not hold --- if part of their site spontaneously becomes viewable, they may not find out for a lengthy period of time, even for an actively-used site.
