Displaying 1 To 16 Of 16 Comments Reasons Not To Upgrade WordPress @Jan Dembowski – “modifying the core files also means you are swimming in the deep end of the pool alone and by yourself” is not necessarily true. If you are prepared to study the code and know a bit about development and security it’s easy to have the best of both worlds. Running your own svn and keeping track of changes, adding the code you want (particularly any security hardening the team includes) is a bit of work but its arguably less work than rolling your own blogging platform/CMS from scratch. I sure wouldn’t recommend this for everyone but its a perfectly valid reason for not updating carte blanche with WP’s auto update and a great use of open source software. » Posted By Elpie On September 28, 2011 @ 9:14 AM While, for the average user, it’s a very good idea to allow WordPress auto-updates let’s not forget that WordPress is an open source system that is specifically licensed to encourage innovation. It’s customisable out of the box but there’s no such thing as “one-size-fits-all” with websites. What suits one site’s content may be completely wrong for another site so forking WordPress makes sense for those users. Tens of thousands of WordPress users are happy to install it and make their sites and content needs fit into what WordPress provides. Others take WP as a starting point then hack the core to give them what they need. Both are equally valid and neither should be subjected to ridicule for their choices. » Posted By Elpie On September 27, 2011 @ 9:54 PM W00t! This is super-dooper, fabulistic news yuss! » Posted By Elpie On June 8, 2011 @ 7:23 AM This must have been a hard post to write. You will be missed here but can move forward with your life knowing you made a difference. » Posted By Elpie On May 26, 2011 @ 10:59 AM I’ve been using Smush.it since it launched. Sure, its handy to have images smushed on upload but this assumes that people are using the WordPress media library. I can’t stand all the image rubbish the media library throws into the database & don’t need WordPress messing with my image sizes, so I don’t use it. I’ve got a routine now – create images, send to Smush.it online, let Smush.it optimise the images & zip them, then FTP the zip file up, unzip on the server and its done. Quick, easy, and no reliance on any plugins. Smush.it won’t break when WordPress updates either ;) » Posted By Elpie On April 6, 2011 @ 7:46 AM How To Mimic The WPTavern Commenting System @M.K. Safi – The way I get around that is by keeping custom functions in a directory inside wp-content, separate to themes or plugins, then using the theme’s functions.php to just call the other files. This way, you can organise functions eg. comment-functions.php, nav-functions.php etc which makes it easy to identify code snippets. Then just include by calling through functions.php. Its a safe way of having custom functions that work across different themes, without the risk of deleting them if you change themes. » Posted By Elpie On March 30, 2011 @ 12:55 AM WordPress Dev Chat For 10-22-09 Oh cool! I got a mention on wptavern – yay! I hope my idea is implemented (Lynne Pope, btw – note the “e” ;) ) and would happily submit a patch for it. All that is needed to make it happen is for the WP core team to commit to using the WP-Announcements mailing list to announce new final releases and whether these include security enhancements or not. Interesting about the trac voting – are you sure its really ignored? » Posted By Elpie On October 29, 2009 @ 9:57 PM Ideas To Improve The WordPress Release Strategy A structured format is really hard to stick to in a volunteer project environment, and creates more work than is necessary. I feel there are only three things that could be done, which would make a huge difference: Use the WP-Announcements emailing list & add a link to this in the README. The ideas for improving alerts in the WordPress backend are good, but don’t help those users who are running heavily customised installs, or who have locked their servers down so tight that they do not get upgrade notices, or see the dashboard feeds, or who manually apply fixes in a company-proscribed process. » Posted By Elpie On September 15, 2009 @ 10:01 PM Do You Think WordPress Is Secure? Just because nobody reported current versions being hacked doesn’t mean this hasn’t happened. WordPress is used by millions of people but we only ever hear from a very small fraction of these. Power users, especially those who understand risks and know how to take remedial action, don’t go to forums to bleat about their site(s) being exploited. An exploit may be reported to WordPress without ever saying that the information was gathered because a site was hacked. I had a site hacked years ago. It was running the latest WordPress of that time & after I found the exploit had been publicly reported in milw0rm I didn’t bother notifying the devs. » Posted By Elpie On September 9, 2009 @ 7:47 AM Danny is wrong – that worm has been in the wild since well before WP 2.8.4. It just hadn’t caused a flurry of activity on the forums till recently. I answered that “its a trick question” because WordPress is not secure. Nor is any other application. All software has vulnerabilities, all web apps are at risk. It’s a simple fact of life that if there is any vulnerability black hats will find it and exploit it. WordPress installs are also at risk from vulnerabilities in PHP, MySQL, the server OS, any server apps such as cPanel, phpMyAdmin, Horde or other mail apps…. the only way to have a 100% secure site is to not have one! » Posted By Elpie On September 8, 2009 @ 9:11 PM This last comment got me curious – how many of those who have commented here actually got hacked by this latest worm? » Posted By Elpie On September 8, 2009 @ 7:34 AM @Ryan – All it would take from the WordPress developers is a simple comment in the code to show where a change has been made for hardening security. If they used a consistent comment it would then be very easy to run a diff and/or grep that comment. If we collaborated on doing this and sharing the patches checking for security fixes would not be onerous. I prefer to see this on the Codex but getting updates on one particular section of the Codex is impossible. » Posted By Elpie On September 7, 2009 @ 7:07 PM @Viper007Bond – Hobbyists or people with too much time on their hands may follow every change in SVN but anyone trying to keep track of development needs to follow trac, the developers blog, the dev site on wordpress.com, and the hackers mailing list. That might work for people like you and me, but it doesn’t work for most users. I think its arrogant of any of us to say why people use WordPress or how they use it. Most of those who are interested in following/contributing to WordPress development only ever hear back from a teeny percentage of users. Fact is, people use it for all kinds of reasons, including the fact that its open source code that can be modified however they want. People do hack the core code – whether they should or not is moot. WordPress updates aren’t updates – they are full installs that just happen to be able to be applied to an existing site. If the database isn’t changed then its only files. Security releases usually only change a file or two so why can’t these be distributed as patches for existing installs? If one line is changed, why can’t the codex show this? It’s a lot easier for anyone who can’t run the update as they can then manually change the line(s) and be assured that their core code is as secure as possible given current knowledge of vulnerabilities. But, hey, let’s get off this “Elpie – you…” thing eh? My comments were based on feedback I get and from interaction I have with others running WordPress sites. None of which apply to me or my own sites. I do manage sites for others that cannot upgrade (for one or more of the reasons I gave) and each of those is as secure as possible. Each also had a line or two of core code changed to match the security fixes plus the addition of the current_user_can check to all applicable admin files. (This is actually one example of why core files get hacked too, because the core could be more secure but current_user_can() is only used in a few files atm). IMO, this latest round of attacks is an opportunity to look at what works and what doesn’t work for WordPress users. Shame if the blame game gets any worse. » Posted By Elpie On September 7, 2009 @ 1:42 AM This post overlooks a couple of things. Secondly, there really are good reasons for some people to not upgrade. Those reasons include clients who don’t want their sites worked on every few weeks, to clients who cannot use later versions of WordPress. Accessibility issues in WP 2.7+ mean some people just can’t use later versions. Other sites use custom plugins that cost them a lot of time and money to develop. Look at the release cycle: June 11 – 2.8 released This is just too fast for any site that is running custom code that has to be tested and may need to be updated. WordPress doesn’t release information on which few lines need changing. They don’t release patch files of only the necessary security changes. With WordPress, its a full upgrade or nothing (or countless hours running diffs through uncommented code to try to find the security patches). It doesn’t take much to post the lines for users to change. WordPress also includes changed/new functionality with most updates, making it even harder for anyone who just wants to apply a security fix. The frequency of releases indicates a branch that has not yet stabilised. When its a continual “patch the patch” going on users cannot be blamed for waiting until their plugins are updated & reports of bugs have settled. Every release of WordPress says its more secure, every time multiple blogs are hacked users are told to upgrade – then that release is hacked. It happens. The sad thing about this latest round of attacks is that WordPress developers have started a blame game. The only ones to blame here are the hackers. » Posted By Elpie On September 7, 2009 @ 12:36 AM Top 5 WordPress Security Tips You Most Likely Don’t Follow @John Adams – A salt is similar to a nonce. It is a type of encryption that uses the secret key to generate a random mashup of the salt + password and sends it encrypted. This makes it harder for anyone to guess passwords or use dictionary attacks against them. The generated password has an expiry time which also helps deter attacks. I’d add another security tip to this excellent list – change passwords regularly and make sure they are strong ones. There’s no such thing as 100% secure passwords and the longer an admin password sticks around, the more opportunities hackers have to decrypt them. Using a tool such as KeePass (http://keepass.info/ makes changing passwords a piece of cake. Use something like that to generate a very strong password (say, around 20 or so characters) enhances the security of the salted password. If the salt is, say 64 characters, and your password is, say 22 characters, that makes for an 86 character password that hackers would have to decrypt, unscrabble and try. It can be done, but it takes time and a hacker would have to be really determined to get in if they were going to be bothered trying. » Posted By Elpie On September 6, 2010 @ 12:48 PM Interesting Question Posed By Andrew I have one site that I am not upgrading from 2.6.5 because (a) it doesn’t need threaded comments, (b) Ozh comment plugin was better than the core replacement, and (c)the 2.7/2.71 UI is slower and less usable. With every releases since 2.6 I’ve found myself using more custom functions and plugins to override the core. With my 2.7+ sites I am blocking auto updates, filtering out the generator tag, wpautop and wptexturize, turning off wlwmanifest_link and rsd and blocking all dashboard feeds. Post revisions are customised. I neither need or want widget management from the core so will probably disable this in 2.8 as well. When it comes to what the software does for my sites I like to have complete control ;) » Posted By Elpie On March 18, 2009 @ 12:28 AMComments Posted By Elpie
Nice to see you are going to be able to stick around now Jeffro. Sadness over now – we don’t have to be miserable any more. This is really great news. Welcome home!
All the very best for your future endeavours Jeff.
Tying announcements to WordPress itself is not practical as it relies on sites having a valid email address (not all do) and also relies on WP being able to access the install. Server permissions may make this impossible.
Release patches, not just full downloads.Where patches can be safely applied to different versions, say so.
Better commenting of code. If code is changed to harden security commenting it would enable users to identify where this hardening has taken place and fix their own code accordingly.
All WordPress users can do is to make their sites as secure as possible and make sure they have a recovery plan.
None of the sites I manage were. Logs showed plenty of attempts, even on the 2.6.5 sites, but all attempts to date came to nothing. WordPress Tavern wasn’t hit.
Was anyone hit or are we all just discussing ways in which securing WordPress could be easier?
Firstly, the reports of sites being hacked is not restricted to just that one exploit. In the past few weeks users have reported various exploits, from the rather common iframe hack to injections of code into the footers of WordPress 2.8.4 sites.
July 9 – 2.8.1 fixes security issues
July 20 – 2.8.2 fixes an XSS vulnerability
Aug 3 – 2.8.3 security release
Aug 12 – 2.8.4 security release
«« Back To Stats Page