Wedge

Because just about every system ever designed to do that has to make the files writable to the webserver. Which means making everything 777. Or you fuck around with creating a manual S/FTP connection, unpacking the update file by file and uploading it via S/FTP that way. While the latter is feasible for plugins, it simply isn't feasible for large-scale updates. And that still assumes the system is actually running FTP or SFTP, systems like IIS won't be. (And believe me, getting it running properly on there is a nightmare)

So if you don't fuck about with S/FTP, you tell people how to chmod or chown (and just look at how many support topics there are on SMF for this) their files, and once it works, they're not going to put it back to secure afterwards.Isn't going to happen. You'll always have people who won't upgrade because they've made custom changes they won't upgrade for, or because they think that their plugins won't work.

But, it's interesting to note that the systems that have one-click updates are more routinely victims of server abuse through files being infiltrated (because of poor permissions setup) than those that don't.

Even putting aside these factors, you're left with an update system that makes the files insecure by default, or an update system that is secure by default but requires users to do some work to keep it up to date. I'd certainly prefer the latter, especially as updates should just be a case of uploading a new set of files, nothing more.

<sigh>

Then no automatic updates for me...

Did you ever do automatic updates for SMF?

How many people are screwed because automatic updates don't work for them? (The number of 1.1.11 updates that failed was pretty vicious, btw)


Note that if someone can show me a robust method for doing it that doesn't require making things insecure by default, I'm more than willing to entertain the idea. But the sheer mechanics of doing it considering the usual mess that is hosts + permissions means I'd rather avoid it entirely, just because that's actually better for the user.

Nope, never did...
But I did do automatic updates for AeMe sitelists, and guess what, never had a single problem with 'em... :P

Do you know why you never had a problem with them?

Apart from the fact that I rock..?

Sadly, it wasn't because you rock, it's because SMF was creating the file by the webserver user itself, meaning that it was implicitly writable by the webserver, and indeed by any other user on the server, which is really no better than the file being owned by the proper account holder but being 777.

The whole point of faffing with FTP/SFTP the way I mention is so that the webserver owner explicitly does NOT own the files, but the FTP user account does (i.e. the user's own account). That way you leave them at the standard 644 and they're not writable, and thus not at risk from tainting.

Well... I'm not 100% sure it's true.
Aeva-Sites.php is indeed generated through SMF, but Subs-Aeva-Sites.php or whatever was included in the package so it wouldn..... Oh, wait, the package is usually installed by SMF. Which would explain...

Well, how 'bout we make Wedge into a package, too? :lol:
I mean -- we ship with a gzip file and an index.php file, and we run the index file to decompress the gzip and install the files with a webserver user ID...

(Of course it's also opening the door to issues when people start FTPing updated files. Hmm.)

Well, I guess FTP'ing the whole stuff is the only solution then. What's the issue with security? Why not use your SFTP component if available?

Because it's still the same basic problem, regardless of whether you use FTP or SFTP.

Scenario 1: the www-data user owns the files. They're writable from Wedge. They're also writable by definition from ANYTHING ELSE that's web-based on the server. That means any rogue process can infect any Wedge file or plugin file with code. This, really, is the risk vector that we're talking about.

Scenario 2: the proper user account owns the files. Then they make everything 777 (and experience says they won't put them back to 644), so Wedge can write the files. Same problem: they're still writable by any other code that's executed via PHP from web requests, which will all be run as www-data.

Scenario 3: we do it as I'm thinking, with FTP. That means we upload it to the server or otherwise obtain it, it'll be in a temporary folder somewhere. Exactly where is irrelevant, because however we get it, the same thing has to occur: it goes to a temporary place. Here's where it gets complicated: whatever we do, we really then have to get into unzipping that file. [1] Whatever we do, we've unpacked the file and we then have to upload it file by file over FTP. For any sizeable package, this is not going to be a quick process, especially if we're talking about a major upgrade. It's likely to then fall foul of the 30 second timeout, amongst other things.


These are the alternatives as I see them, and I don't like any of them that much :/

1.	We end up dumping it all into system-wide temporary folder, where it's also at risk, though there's no guarantee the files will actually be left available over any period of time. It's really a side concern though.

So your saying caching the data takes more time then if I processed all the urls in a page?

I wasn't too sure which would be faster when I made the modification to do file caching instead of db. I know the file caching has to be faster than the db, not only faster but you don't have to worry about the DB being filled with junk that never purges. Both can be turned off easily anyways.

However I know you and Arantor, always bickering over performance and slight gains, which isn't a bad thing. So I am pretty sure your information is correct. Thanks though for the information, I think I am going to disable caching completely in that area.

It's not a simple x is faster than y argument, either. If you have stuff in the DB that's being called frequently, assuming you don't have a stupid DB layout and bad queries, there's a reasonable chance that you might be able to get some of that stuff out of the query cache, and if the table isn't too huge, you might even get it entirely into memory anyway, and RAM is faster than HD for things like that ;)

The method in the VB's script is not DB friendly. The URL DB cache for most people out grows everything else in the DB. Before I noticed it, the URL DB cache was taking up at least 3/4 or 75% of my DB. That is when I suggested to VB to use SMF's cache and also give the option to disable, because that is better than the DB option IMHO. Plus who wants 75% of their DB just used for Pretty URL's.