tires Posted April 2, 2015 Share Posted April 2, 2015 Hello! I saw that there was a new PW update (2.5.24) on march 27th. My general quastions - as a pretty processwire newbie - do i have to update all my PW-sites immediately because of security reasons? What would be your advice? How dangerous is it not to do an update? How do you handle this? Is there a way to automate the updates? Many thanks and best regards! Link to comment Share on other sites More sharing options...
adrian Posted April 2, 2015 Share Posted April 2, 2015 There are currently no known security issues in any version of PW, but I still like to update because of all the new toys (https://processwire.com/blog/) and bug fixes. Personally I like updating via git pull, but this module also makes it super easy: http://modules.processwire.com/modules/process-wire-upgrade/ Enjoy the ride 3 Link to comment Share on other sites More sharing options...
kongondo Posted April 2, 2015 Share Posted April 2, 2015 I can assure you that the recent updates have nothing to do with security ....they are all to do with improvements to performance, added functionality and bug fixing. Some people prefer to use the dev branch of ProcessWire whilst others even stick to older versions 1 Link to comment Share on other sites More sharing options...
tires Posted April 2, 2015 Author Share Posted April 2, 2015 Thanks a lot for the answers!!! A few further questions: What about the compatibility of (older) modules with an newer/updated PW version (as known in drupal)? Or is there no risk? Is there a way to update the core or the modules automatically or with a click just out of the backend (as known in wordpress)? (I saw that the ProcessWireUpgrade module do this) Is PW so absolute save or so small that actually no one tries to hack it? ;-) By the way, is there a maintenance-mode in PW that i can switch on while performing updates? (I found this module http://modules.processwire.com/modules/maintenance-mode/) Many thanks and best regards! 1 Link to comment Share on other sites More sharing options...
horst Posted April 2, 2015 Share Posted April 2, 2015 I do not update older installations with new releases until I want to add some of the newer features. I today run sites with PW 2.3. There is no security reason to update those. 2 Link to comment Share on other sites More sharing options...
cstevensjr Posted April 2, 2015 Share Posted April 2, 2015 There is no safe or secure software application. The only thing you can do is use good coding techniques, apply time tested security practices and have a great understanding of whatever you are doing. Proofing your work for errors and have a bit of luck helps also. 1 Link to comment Share on other sites More sharing options...
tires Posted April 2, 2015 Author Share Posted April 2, 2015 @horst: Thanks! Good to know. But when i want to update (because of bugfixes or new features) do i have to fear from uncompatibility to some older modules? What are your experience? @cstevensjr: Ok, but all the coding i do in PW is "echo" fields and some "for each" an "if". So i think that should be pretty save!? The question is, if PW is pretty save also? Link to comment Share on other sites More sharing options...
LostKobrakai Posted April 2, 2015 Share Posted April 2, 2015 There's always the possibility for bugs when updating any software. That why you should always update on a staging/dev environment before doing it in production. I've not experienced any reworks in ProcessWire which would've broken anything without at least incorporating a fallback, so modules should at least work for a whole mayor release cycle. In the modules directory there's a field indicating compatible versions for each module. Regarding the savety issue. ProcessWire does even provide lots of functions to make it easier for users to secure their code (CSRF, session fingerprints, sanitizers) and like mentioned above already, there are currently no known security issues with ProcessWire. 2 Link to comment Share on other sites More sharing options...
teppo Posted April 3, 2015 Share Posted April 3, 2015 When it comes to security, one important thing to note is that Ryan has taken a very strict approach to that in ProcessWire. Our codebase is clean (free of unnecessary clutter and legacy stuff), attempts are made to mitigate known attack patterns, and strict filtering is applied before requests even reach the system itself in order to protect it from possible future attacks. ProcessWire 2.x may have it's roots in much older systems, but it's also a complete rewrite, built from the ground up for it's current design philosophy and set of features. Not having a huge user base isn't the most important factor when it comes to the amount of existing/found vulnerabilities, even if some folks out there like to claim so. There's a lot more to software development than that, and the truth is that not all software is born equal. In some ways it's actually unfair to compare ProcessWire with some of the older projects out there. Not only did some of them start out as something entirely different and just grow organically (and without much planning) to what they are now, they've also got a lot of legacy payload under the hood. By legacy stuff I mean features they can't remove in fear of breaking backwards compatibility and/or can't rewrite because it'd be an enormous task. It's true that we're still relatively young, small, and agile, and for the most part simply don't suffer from those issues.. but it also looks like we might be able to keep this up for a very long time. Some of the key factors here are not leaning too much on the idea of "never break backwards compatibility", making the right architectural choices (API design, etc.) and honing our development process all the time. As a side note, regarding ProcessWire modules, the quality of those is pretty good too. The amount of 3rd party module authors is still limited, and so far we've been able to, more or less, go through each new module submission and make sure it's quality is acceptable. If we had tens of thousands of modules, that'd be pretty hard to pull out, I'll give you that. 4 Link to comment Share on other sites More sharing options...
Pete Posted April 3, 2015 Share Posted April 3, 2015 The only security vulnerability I can remember was in my own Minify module (not to be confused with AIOM) as it relied on this library: https://code.google.com/p/minify/ however as soon as I was made aware of that it was patched and updated. I can only echo what others have said above - you can never say with 100% certainty that there won't be a security issue discovered in software of this size, especially when coupled with all of the possible web server platforms and server module combinations. There are too many variables for anyone to say with certainty on any project that a security issue won't be found. There is more likely to be issues arising from our own code (not sanitising user input etc) than in the core though (that's my own experience anyway). The default templates even with search capability (user input right there) are build with best-practises in mind and offer several different ways you might want to build your front-end, but it's usually when you start doing your front-end work that you have to be careful - obviously PW is one of those rare projects where you don't need to upgrade a site if it works. If there were to be a vulnerability discovered, I would wager that you would have an easier time upgrading than with many other projects though (your front-end templates just won't instantly break for one because the API calls all remain the same!). I have been, for the last almost 4 years (wow, that's flown by) pleasantly surprised by the lack of a need to keep things up to date. I've never used Wordpress for my own sites so haven't suffered that rapid upgrade cycle, but have used MODx where every so often I've had to patch multiple sites. Now pretty much everything is on ProcessWire for me I've not had to do any of that. Choosing when to upgrade based on new features that might benefit the client, or might enable me to sell additional services to the client - that is the position we should all be in, not dropping everything to upgrade every couple of months But yes, the final line on security should be that none of us can say that a security issue will never arise, just check your module compatibility when upgrading (and it's best to test those modules locally as well because I think most will work on newer versions even if the module pages in the directory haven't been updated) and you should be fine. 3 Link to comment Share on other sites More sharing options...
tires Posted April 4, 2015 Author Share Posted April 4, 2015 Thanks for your detailed anwers! If i understand you right, the system is pretty save. And i have to be careful with my template code and where userinput (comments, search etc.) happens. Right? As i just read here https://processwire.com/talk/topic/9565-upgrade-from-2524-to-2525-broke-the-site/ updates may cause problems with modules. Or is that a rare exception? Link to comment Share on other sites More sharing options...
LostKobrakai Posted April 4, 2015 Share Posted April 4, 2015 That's why all of us suggest doing updates on dev environments. If there are problems just wait till they are sorted out. Just do not update live sites and expect it to work every time. Additionally it's still the development version that most of us use, so it's natural that problems can arise, but if so report them and sooner or later they will be sorted out. As said before there's currently no need to update for other reasons than access to new features. Regarding userinputs: Sanitizing them is what you need to do no matter which cms you use. As soon as you do implement functions where users can directly input data you need to make sure it's not harmful data. So if you're for example using the core comments systems that's already implemented, but with ProcessWire's nature of encouraging to build own systems you need to be aware of the potential of malicious input from users. For example anywhere you accept data from forms or from parts of the url you need to consider that a user could abuse those points of access to inject own logic. 2 Link to comment Share on other sites More sharing options...
tires Posted April 4, 2015 Author Share Posted April 4, 2015 Thanks once again!!! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now