Considering this is the #1 thing that can be done to speed up SMF, I strongly suggest this should be done for 2.0. It's a trivial change, too. All it involves is another directory created in the installation and a setting.

When I did some analysis a while back, I found enabling this saved 75 PERCENT CPU usage. For the work involved, it's totally worth doing.

Agreed. I see no good reason uploaded avatars should be passed through PHP by default, particularly with the number of them which may be loaded with every topic view. It makes sense for regular uploaded images to track views or whatever, but not avatars.

Well, if we do that by default, then the hashing of filenames, as it is done currently by default (post SMF 1.1.9/RC1-1), with practically the effect of making the filenames impossible to guess, doesn't happen anymore, obviously. It was done to introduce a little new layer of protection against a malicious avatar/attachment.

The whole point of the change was, indeed, against a malicious avatar; the idea being that you could upload a malicious PHP or similar file and if you know its location, execute it.

Avatars are not those, however. They are image files, pure and simple. If it's not an image file, prevent it from being uploaded, simple as that.

Btw, it isn't actually possible to disable filename hashing from the admin UI after those versions (though you could theoretically do so via the settings table directly).

Question: if it was that much of an issue for security, why wouldn't this forum do it the same way?

Question: what security benefits do you actually get serving what you should *know* to be an image through an obfuscation layer? There are, of course, benefits to serving a potentially non-image file through such (to minimise/prevent server execution) but I can't see any you would gain from applying the same to image files being served as images.

>> Question: if it was that much of an issue for security, why wouldn't this forum do it the same way?

It isn't much of an issue for security.
It is IMHO, however, a stronger setting, than the opposite. None is a problem though, otherwise it wouldn't be even a setting in SMF.
The issue here is not that any setting is a security problem, because NONE is. BOTH are fine.
It's whether a little extra-layer of protection should be the default setting or not.

>> Question: what security benefits do you actually get serving what you should *know* to be an image through an obfuscation layer? There are, of course, benefits to serving a potentially non-image file through such (to minimise/prevent server execution) but I can't see any you would gain from applying the same to image files being served as images.
You don't necessarily know. They are not necessarily image files being served as images.

Well, consider this. Let's assume we have a topic page with a default of 15 posts, each by a different user, and every user has uploaded an avatar. With the default uploaded avatar handling, that's 15 more instances of PHP which have to be loaded to handle displaying all of the avatar images for that single page. Ouch.

You do have a point that the current default handling is slightly more secure, to prevent fake images with PHP content from being executed on server setups which are vulnerable to such an attack. It's just a matter of weighing that against the major performance hit which it can cause.

Yeah, the killer isn't so much the SMF PHP scripts, but the compiling and parallel execution of said scripts, especially when not running an opcode cache. The recent changes have made loading an attachment about twice as fast. But with a brain dead web server like Apache that spawns a new thread/process for every request, not having a custom avatar directory multiplies the number of threads/processes required to serve SMF.