InstantUpgrade Beta Released

There Are 10 Responses So Far. Jump To The Comment Form And Join In

1. Comment by Alex on 11 February 2008

   Jeffro, thank you very much for spreading the word!

   Reply - Quote



2. Comment by Chris Thomson on 11 February 2008

   I used to use InstantUpgrade before I switched to SVN. I haven’t tried InstantUpgrade, but the one thing I didn’t like about it, was that it’d remove all files, before uploading the new ones, leaving your site unusable for a minute or two (index.php was removed, of course). For those who don’t feel comfortable with SVN, or don’t have shell access to their site, I’d definitely recommend InstantUpgrade.

   Reply - Quote



3. Comment by Jeffro on 12 February 2008

   @Alex No problem Alex. If the InstantUpgrade plugin ends up being fully integrated into the core of WordPress, will development for this plugin be discontinued?

   @Chris Thomson Hey Chris, you’ll have to write up a post about what it’s like running a WordPress blog on Subversion. Maybe include some pros and cons between running a normal version of WordPress versus Subversion. I’d be interested in something like that.

   Reply - Quote



4. Comment by Kaspars on 12 February 2008

   Hey, Jeff. I think you mentioned this plugin in the previous podcast, which made me think a lot about how easy/difficult/secure the file updates from the “inside” of the server are.

   The only arguments against such plugins are the usual ones:

   1) users of the same web server (on shared hosting accounts) can gain access to files on other accounts of the same server due to the read/write file permissions.

   2) If this single plugin has a security hole, so does the rest of the website, because the plugin has full read/write access rights to other files on the server (of the account).

   Therefore, I would never use such plugins myself, although I understand the complexity of the update procedure and how some people may be put off by it.

   It would be much better to create a single resource (a wiki, maybe) where more savvy users can post ftp instructions for the webhosts they are using — to make a centralized resource available to everybody.

   Reply - Quote



5. Comment by Jeffro on 12 February 2008

   @Kaspars I think you bring up some excellent points. But simplicity appears to outweigh security. I don’t know how BIG of a threat this plugin could be, but the mere fact that WordPress.org is actually trying to integrate the functionality into the core could be a representation of the lack of security threats involved?

   Reply - Quote



6. Comment by Alex on 12 February 2008

   Jeffro:

   If the InstantUpgrade plugin ends up being fully integrated into the core of WordPress, will development for this plugin be discontinued?

   Well *if* core devs would decide to take this plugin into core, which would be a great honour, then development would be just beginning. I don’t know how the chances are, but I have some great ideas for future releases, like multisite updates (if you have multiple blogs, you can upgrade them all from one installation), and some other cool stuff. But all the improvements have to wait until the FTP feature is well enough tested, because this is really important for the whole idea of automatic upgrades.

   Kaspars:

   1) users of the same web server (on shared hosting accounts) can gain access to files on other accounts of the same server due to the read/write file permissions.
   2) If this single plugin has a security hole, so does the rest of the website, because the plugin has full read/write access rights to other files on the server (of the account).

   As for 1), it would have to be a pretty bad server setup where other users have access to your FTP directory. Usually FTP dirs on shared hosting servers are chrooted. *If* they do have access, they have read permissions on most files anyway, just like on any Unix/Linux server you can read other users’ directories (dunno about Windows). Most files are world readable, but only writable by the user. The plugin can only do what the FTP or HTTP user can also do. Btw, you might have misunderstood the part where all WP files are made world-writable: This is only for some minutes before the first upgrade, and only relates to v0.2 — since the new one uses FTP, we can simply act as the FTP user, who has all permissions anyway.

   As for 2) I agree that an attacker who gains raw access to the database could obtain the FTP account data. Unfortunately, there are enough plugins that have security problems, so this isn’t even too unlikely. I’ll think about a way to encrypt the FTP data in the database.

   Reply - Quote



7. Comment by Kaspars on 12 February 2008

   Alex, thank you for such a detailed response.

   I would like to emphasize that I absolutely love this idea of being able to automatically upgrade WordPress core, and I think that you have done an amazing job by creating this and making it available to everyone.

   My initial idea of how the plugin works was the following:

   1) user activates the plugin and makes all the directories writable using their own ftp client (chmod 777 for all files and dirs).

   2) InstantUpgrade takes control of all files and dirs (using the server’s user under which it operates) and makes them chmod 766 (or something).

   3) Each time a new version of WordPress is released, the plugin downloads the archive file using either of PHP built-in http request functions (file get, curl).

   4) Deletes the old WordPress core files and extracts the downloaded archive (leaving some files/dirs intact).

   If thats how it works, then:

   I agree that the point (1) mentioned in my previous comment (about the users on the same server) is indeed valid only if the server setup is really bad. Nowadays this is very uncommon. Such vulnerability would be dangerous to any server system.

   But point (2) I think is still valid, and is basically the single most important issue of such plugin functionality. Full system file access is my only concern.

   Keep up the great work, Alex! I honestly think that this can be made very secure, if done right and scrutinized very carefully. If I’ll have any suggestions after going through the code, I will definitely let you know.

   Reply - Quote



8. Comment by Kaspars on 12 February 2008

   I just downloaded the new beta version and the way it works is much different then I described. Now the server connects to itself (through FTP) and does all the replacing through http://FTP.

   This is much more secure. It would be even equal to the manual updating if the FTP username/password was not stored in the database, but requested from the user every time the update is initiated. It shouldn’t be too much of a hassle for the user to provide this information, as it would happen only once in a few month.

   This is really great! I think I’ll actually try it out very soon

   Reply - http://FTP.\n\nThis is much more secure. It would be even equal to the manual updating if the FTP username\/password was not stored in the database, but requested from the user every time the update is initiated. It shouldn\’t be too much of a hassle for the user to provide this information, as it would happen only once in a few month.\n\nThis is really great! I think I\’ll actually try it out very soon :)’); return false;”>Quote



9. Comment by Alex on 12 February 2008

   Kaspars, I’m glad you like it. I thought about the security issue, and decided that there is no secure way of storing the FTP password in the DB. (There might be one, but I’m not a security expert, and all possibilities I thought of were insecure and/or inconsistent in the end.) I will release a beta2 that will store all data *except* the FTP password in the DB, and request this password on each upgrade. I think this is a good balance between security and convenience.

   Reply - Quote



10. Comment by whitetern on 3 April 2008

    Any of you guys tested this plugin in a wordpress hosted on Yahoo? does it upgrade to 2.5 without any problems? thanx

    Reply - Quote

The Water's Warm, Jump In The Conversation