Wedge
Public area => Bug reports => The Pub => Archived fixes => Topic started by: Arantor on October 29th, 2012, 04:18 AM
-
Sort of putting this in right here, right now.
None of the add plugin stuff works, mostly because I haven't figured out a way that doesn't suck that works without being insecure for uploading plugins.
-
Is it possible for Alpha testers to download themselves and apply manually?
-
Pete, you need to start giving up on 'good UI', and just going for 'UI' ;)
You're free to rewrite it later anyway! That's what 'new versions' are for...
-
It's not UI at all. It's fundamental security issues that I'm talking about... The UI that is needed is only marginally more than what is there. But I WILL NOT release a version that is insecure by design. I'd rather remove the 'add plugin' stuff and make it so people have to use FTP themselves than crank some half assed solution.
@Powerbob: You can unpack them and upload them to the Plugins folder in Wedge. That's one of the truly great things - uploading a plugin will make it available immediately and since no file changes can occur, that's all that's needed to get it there, then it's just a case of clicking the button to enable it. Disabling, generally, should work the same way, you can just remove or rename the folder to disable it (though, depending on what it does, that is not necessarily ideal)
-
I'd say use FTP (SFTP) and forget upload by PHP. Should anyone besides the root admin be able to add new plugins too his site?
-
I don't see why anyone besides root admin should be able to do so.
On the other hand, in theory the upload could be done via FTP anyway and have PHP handle that connection, but that raises a great many other issues (like avoiding timeouts and the potential contamination via temporary folders)
-
Suggesting that we disable that feature entirely from the UI. That way, we won't get reports on how it's broken...
Also, right now we're using AeMe to upload plugins, and I'm not sure I can find a reason to switch to another system later. So, perhaps we could at the very least retrieve a list of items that are in that particular album. ;)
-
Also, right now we're using AeMe to upload plugins, and I'm not sure I can find a reason to switch to another system later.
I have thought about simply removing it entirely, but all the time it's there, I can keep telling myself that I'll finish it - if it is removed, I'll stop thinking about how to make it work well, which also means not worrying about things like auto updating.
-
We can still use AeMe to host the plugins, and develop a mini-plugin that will help communication between AeMe and Wedge auto-downloads.
-
Putting aside everything related to repos and repo management (though that is a todo), I've been working on this stuff.
The FTP class has been extended to support uploads and downloads, though that's a work in progress and will require more work yet.
There's also a zip handling class coming, that when combined with the FTP class, should make it possible to upload plugins, though admins will have to provide FTP details, and lots of stuff behind the scenes to hopefully make it work on various shared hosts.
The only caveat is that the zip library I'll be adding is LGPL and I've made quite extensive modifications, so to fulfil the licence we need to be able to distribute it standalone. No biggie, there's no Wedge specific code in it.
-
Couldn't you use Zip_Archive?
-
If you mean the PEAR library, it's unmaintained and had PHP 5.3 issues.
If you mean the not-installed by default class, that doesn't do what I need, nor can be cajoled into doing what I want as far as I can tell.
-
Just to expand when I'm not using an iPod...
SMF has a zip handling library, except it doesn't work on some zip files, Plus it's also about just unpacking the entire archive in full into a local directory which is not what I want.
ZipArchive (in either form) tends to do much the same thing, though both are more capable of handling zip files.
What I need, ultimately, is something that can handle as much of zip files as I can throw at it, and on top of that, I need it to be able to handle extracting files one at a time - and here's the bit that ZipArchive can't do - and I want that file to be pulled into a variable, I do NOT want it pushed out to a file in temp/ not even temporarily.
See, here's how this is going to work. The setup is geared for being able to process this across multiple page loads, so I need to be able to pull things from zip files at will, and I want as little as possible to be in the temporary area. Since the upload must go there by definition, I can't change that, but I can prevent new files appearing in temp, which will be subject to pruning by the operating system and will be subject potentially to tampering from other scripts.
Once I've uploaded the file, I can extract it piece by piece and send that to the server via FTP (and as I understand it, can make this faster by only opening one pair of connections rather than the typical one connection the whole time, one connection per file, but I might have that understanding of FTP wrong)
Hmm. Now that I think about it, actually I can't do it that way. I'm going to ditch the current SFTP class and reimport phpseclib - into its own folder. Condensing the files is rather time consuming and there's been substantial changes since I did it a year ago, so I'll just import the entire library as-is.
I won't be doing that with the PclZip class, because it isn't forwards compatible with PHP 5.x, but also it isn't 'actively maintained', as the last release was in 2009. (Also, of note, the author of PclZip was the former maintainer of the PEAR ZipArchive)
-
TBH I think downloading a zip/arc file to my PC, and extracting it, and then uploading the folder to the plugins directory is very easy as such! I think it's fine as it is. Do we really need an "add plugin option"? I don't think so, but hey what do I know :whistle:
-
Given how many people seem to have trouble with even the most basic of tasks, I've been wondering the same thing, but on the other hand, if the framework is there for such things, it's also going to be possible to do things like plugin updates.
Cutting this out cuts out a *lot* of other stuff too.
-
Hold on, PHP doesn't have a single functioning Zip manipulation library that is current and can be used for browsing?
-
Not browsing how I want it, no.
-
So you don't got a solution ATM or you're writing your own? I still am not completely sure why you're avoiding a tmp folder extraction, I understand it's most probably security reasons and that files can be left behind and be accessed directly from HTTP posing a security risk.
-
Oh, I got a solution. I found a zip extraction library, but that it needs some clean up. Like using a proper __construct method, stripping dozens and dozens and dozens of lines of stupid and useless comments (like // ------ Return, just before a return statement) and general cleanliness stuff.
That and the fact that I've already stripped 55KB off the original 199KB by cleaning the code up.
OK, here's the underlying logic.
* The core Wedge files and folders should never be writable by the webserver under normal circumstances. The single greatest reason for things being hacked is files being writable when they shouldn't be, on a shared server. Thus, the files not being owned or typically writable prevents that from being the case.
* We don't have a temp folder anywhere in the Wedge installation for this reason, and I'm loathe to make one for the above - doubly so when it's directly accessible via user-side HTTP. Given how much hassle SMF has with its temp folder being added/removed, I want to avoid it entirely.
* This means any temp file is going to be in the system temp folder - where the upload is going to go anyway. But the system temp folder is writable by any user. As a result, anything that goes through there is potentially open to contamination. Once stuff is extracted, it's pushed via S/FTP to the plugins folder where it is essentially live. As such it absolutely has to be as safe as it can be - and everything I can do to prevent contamination on the shared server, the better.
* The other problem with system temp folders is that you can't guarantee the lifetime of any file. Limiting it to just the uploaded zip file is one step to protecting that.
I don't think I'm being particularly paranoid, or suffering from NIH, but this is the weakest part of the system and short of just dropping it and forcing everyone to upload manually (which as I stated does also prevent things like updates being handled well), it's a no-go.
Note that even without the zip component, I'd still need to do a lot of the same for things like handling smileys, the same deal with uploading via S/FTP is going to be the case.
-
Doesn't this problem by definition extend to attachments and AeMe uploads as well?
-
Yes, of course it does.
But for attachments and AeMe uploads, at least there is a layer of insulation. It's not executing that code directly, or at least it shouldn't be. (And there are .htaccess rules to prevent files being requested directly and to prevent PHP execution)
It's one of the long-standing issues in PHP and web server design. In the truly separated spaces, single site on a VPS for example, this wouldn't be a risk because you wouldn't have other users to contend with (only flaws in your running applications stack, but that's a given) - we're dealing with the state of play on a shared server, where by definition there are tons of other users on a server, all of whom have the ability to access those files by definition - they have to be writable by a user who isn't the file owner.
The difference, ultimately, is that attachments are other uploads are a calculated and considered acceptable risk. They shouldn't be called directly, nor executed, so the risk that they get malware or similar is actually small - there's not a significant payoff in compromising those files.
But if you can compromise live PHP on a site, it's going to try to compromise anything else on the server - there's a payoff in doing it.
-
OK, so progress has been surprisingly slow on this given the dozens of KB of code that's had to be written thus far. But progress is happening. So far we've got through uploading, through validation of the plugin being a valid, unpackable zip and dealing with duplicates.
Now we're up to getting FTP details, and most of the handling for that is done, even down to attempting to find the right FTP path with a less than pretty method (but, hopefully, reasonably reliable)
All WIP of course but I thought you might like some screenshots.
-
Just great!! :))
-
Looks good, like it :lol:
-
I just love the fact that plugins don't require code changes to source files. I mean that's just brilliant!