People wanting to use the formats: archive/zip up your work and upload it. It's not hard (either through GUI or CLI). The end.
I have made changes to the following categories of allowed extensions.
- "Active content" that may accidentally be executed in the browser context, causing cross-site scripting:
Removed .swf, .js
Removed .html, .htm, .xml (because <script> element and on* attributes)
Did not add .svg, .xhtml (because <script> element and on* attributes)
- Common CGI languages that may accidentally be executed in the server context:
Removed .php, .py, .lua
- Compiled languages:
Added .cs, .java
- Chip music scores:
Added .0cc, .ly, .pently
Ah, but who allowed .php in the first place?koitsu wrote:I shouldn't have to state stuff like this.
https://forums.nesdev.com/viewtopic.php ... 34#p127134
I'm a little disappointed to see .lua removed (there's been lots of cool FCEUX lua scripts shared in the past), and .py but whatever. More zips I guess. (I was the person who asked for both of those in the first place.)
Was either .js or .php ever actually requested? .swf?
Yes, that's what I was disappointed about. The friction of un-zipping propagates also to each person who wants to download it too.tepples wrote:You can still upload Lua scripts. Just zip them up first
I understand that part. Whatever you feel is necessary to protect the server is fine. I don't know anything about what your server's configuration looks like, so I'm in no position to tell you what's safe for the server, but as an end user I'm still disappointed that something I liked using (both up and down) is being removed.tepples wrote:so that they don't accidentally get executed on the server.
Especially because this makes several old posts inaccessible, without even being shown a filename or any information to cross reference what might have appeared there with files I might still happen to have downloaded. It's a bit frustrating to have content you uploaded to the BBS for archival purposes suddenly effectively "deleted" with no identifying reference...
Like I would have a hard time finding my affected posts at this point, and then also knowing what content is actually missing is also a problem with this interface, and then even if I knew the filename I'd have to hope I still have a copy somewhere else that I can zip up and edit back into the post.
So... my disappointment is a bit more than "just" having to zip some files up in the future.
If you need to have them disabled for security reasons, I'm not trying to fight about that, you can weigh that as you need to, I'm just telling you how I feel about it as an end user, but is there anything you can do about old posts, at least? From my side I have no way of finding or recovering the now blocked content. That stuff is actually quite frequently useful to me. (Plus even if I had, e.g. a grace period and list of my own affected posts... that still doesn't work for anyone else's old posts who's not currently watching the issue and actively working to update with zips.)
I think the server infrastructure changed between then and now (including the webserver, IIRC; it used to be Apache, now it's nginx, and I think there's a reverse proxy involved now). What I knew to be true then I don't think is true now.rainwarrior wrote:Ah, but who allowed .php in the first place? ;)koitsu wrote:I shouldn't have to state stuff like this.
https://forums.nesdev.com/viewtopic.php ... 34#p127134
MIME types can be treacherous territory; server-side they seem innocent enough ("it's just a Content-Type header!"), but when reverse proxying is involved or potentially other devices like load balancers, all of which tend to inspect content, it becomes risky. Apache's mod_mime_magic can be a blessing and a curse too. Often feels that the days of basic web hosting/content serving are long gone. Things were simpler back then (code directly on an Apache webserver which was directly on the Internet, no intermediary anything).
Reviewing the download links from phpBB (example), we can see that the Content-Type returned (at least for a .zip) is application/octet-stream -- good -- and a Content-Disposition type of attachment-- which is correct and VERY important -- but the rest of that header looked bizarre to me (those are two apostrophes next to one another BTW, not a double-quote; the asterisk also made me go "?!?!"):
Code: Select all
$ curl -s -v 'http://forums.nesdev.com/download/file.php?id=10609' * Trying 188.8.131.52... * TCP_NODELAY set * Connected to forums.nesdev.com (184.108.40.206) port 80 (#0) > GET /download/file.php?id=10609 HTTP/1.1 > Host: forums.nesdev.com > User-Agent: curl/7.59.0 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx < Date: Sat, 05 May 2018 03:28:01 GMT < Content-Type: application/octet-stream < Content-Length: 284 < Connection: keep-alive < Keep-Alive: timeout=60 < X-Powered-By: PHP/5.5.9-1ubuntu4.20 < Set-Cookie: XXX < Set-Cookie: XXX < Set-Cookie: XXX < Pragma: public < Content-Disposition: attachment; filename*=UTF-8''700-in.1_32kib.zip < Last-Modified: Tue, 31 Oct 2017 22:49:03 GMT < * Failed writing body (0 != 284) * stopped the pause stream! * Closing connection 0
Finally, client-side MIME type association is often a crap shoot as well -- you have no control over how someone's browser is set up/configured, so you don't know what will happen if the client receives a true/literal Content-Type that matches a MIME type that they've configured to allow to auto-run (e.g. "Download as..." vs "Open file"; scarily, a lot of people still do the latter, either automatic or manual). For example, we don't know if someone has .bat set to automatically run cmd.exe on it, and some jackass uploads one that does @echo off\rrmdir /q /s C:\WINDOWS. The idea is to minimise the chance of something like that happening. TMK, phpBB doesn't do any kind of "filtering" or "scanning of content" on uploads -- and I tend to fear stuff like that anyway (false positives causing failures that drive the uploader crazy).
Out of idle curiousity (not anything actionable), do any of the python scripts you've uploaded show up in the Manage attachments list?rainwarrior wrote:It's a bit frustrating to have content you uploaded to the BBS for archival purposes suddenly effectively "deleted" with no identifying reference...
Ah, yes they do. At least there's a list of my own posts I can access then. (...and yeah, can see the filename and thread but can't download.) I thought I'd uploaded more lua scripts than python, but apparently it's the other way around.lidnariq wrote:Out of idle curiousity (not anything actionable), do any of the python scripts you've uploaded show up in the Manage attachments list?rainwarrior wrote:It's a bit frustrating to have content you uploaded to the BBS for archival purposes suddenly effectively "deleted" with no identifying reference...
You can decide how and whether to work on this. I'd volunteer to help, if I could, but I don't think I can really do much about it as a non-administrator. (If there is work I can do to facilitate this, though, let me know.)tepples wrote:...am I now expected to (solve this problem)
I would suspect/hope that for most of them, the number of affected files is actually zero, but .py and .lua specifically are ones I'd been using and seen others using too. (It's possible this affects my posts more than anyone else's... I know I'm responsible for requesting these two formats in the first place.)
With 12500-ish current attachments on the forum that's a little too big to just manually check without explicitly getting WhoaMan's OK.