Introduction About Site Map

XML
RSS 2 Feed RSS 2 Feed
Navigation

Main Page | Blog Index

Friday, October 10th, 2014, 4:27 pm

Health Club Awards 2014

Health Club Awards 2014

The Midland Hotel’s health club, the club I have been going to since my teenage years, has won Health Club Awards 2014 for the north west and ranked 3rd overall nationally. This is the second year running that our club wins this award and today the staff took this photo of Rianne and I with the awards for this year. The staff there is wonderful.

Friday, August 29th, 2014, 8:29 pm

How to Patch Drupal Sites

My experience patching Drupal sites is years old and my general ‘policy’ (habit) is to not upgrade unless or until there is a severe security issue. It’s the same with WordPress, which I’ve been patching in several sites for over a decade. Issues like role escalation are not serious if you trust fellow users (authors) or if you are the sole user. In the case of some agencies that use Drupal, it might be safe to say that the risk introduced by change to code outweighs the safety because as far as one can tell, visitors of such sites do not even register for a username. All users are generally quite trusted and they work closely (one must have checked the complete list to be absolutely sure). There is also ‘paper trail’ of who does what, so if one was to exploit a bug internally, e.g. to do something s/he is not authorised to do, it would be recorded, which in itself acts as a deterrent.

If the security issue is trivial to fix with a trivial patch, then I typically apply it manually. When the SQL injection bug surfaced some months back that’s what many people did for the most part. For larger releases (not bug fixes) the same applies, until there is no other alternative. What one needs to worry more about are module updates, especially those that are security updates. One should make a list of all modules used and keep track of news or new releases (watching general FOSS news is usually not enough until it’s too late). Thankfully, detailed information on what the flaws are becomes available, along with associated risks both for core and additional/peripheral modules.

Then there’s testing, which I guess one needs to do for any changes that are made, assuming time permits this. The last major Drupal flaw had a 7-hour window between publication and exploitation in vast numbers (maybe millions). It means one cannot always follow the formal procedure of testing, albeit testing in an ad hoc way or minimising the risk by applying a patch ought to work well. This leads me to suggesting that developers don’t need to have one uniform workflow/process for changing Drupal but a multi-faceted one. Proposal:

If the flaw is

1. severe
2. not back-end (i.e. not related to role management)

consider the complexity of the patch and test immediately on an existing copy of the site, then deploy on ‘live’.

If the patch is a core patch, no alternatives exist. If the patch is to be applied to a module, study the effect of disabling the module (assuming no dependents), consider temporarily keeping it out of reach (public site/s).

For less severe flaws:

1) merge into git on a dedicated branch
2) test on a local vagrant installation
3) schedule for deployment to “development” for testing
4) schedule for deployment to “staging”
5) run regressions (one needs to define these)
6) Client to do any required acceptance testing
7) schedule for deployment to production.

Suffice to say, the changes should not only be made through git (not directly) but a database dump too (or snapshot) should be taken, both for quick fixes and for longer testing purposes because even if changes are revoked (git rollback) the database can be left in a sub-par/inadequate state.

Regressions of interest for Drupal are not just site-specific. There are some nice templates for these and one needs to consider which modules to use in the site. Intuition and general familiarity with the CMS loop/hooks help one predict what impact a change would have on modules, if any. Drupal has good documentation of functions (by names), so these too can be studied before changes are made. To avoid some modules ‘silently’ breaking, following any change to core (or even modules) one may need to go through a list of tests. specified in advance, that help verify no module spits out PHP errors or behaves oddly. It is common to test critical pages first, e.g. finding an authority, research reports, etc. Sometimes it should be possible to also automate the testing by basically making local snapshot of pages of interest and then diff‘ing them after changes are made, using sophisticated tools like Versionista or a manual side-by-side comparison by a human operator. There are browser extensions that further facilitate this, but caching such as Cloudflare, varnish cache etc. can impede this process (even though changes to underlying code may invoke an override, at least for varnish).

Regressions are nice, but in many cases developers don’t have time to run them and a simpler set of manual checks can help gain confidence that changes made have no detrimental effects.

I cannot recall ever having major issues patching (as opposed to upgrading) the core or WordPress and Drupal and I have done this hundreds of times. The quality of testing when it comes to core (not external/additional) is quite high, but another worthy step is, before making any changes, look around forums to see what experience other people have had. There were cases where patches were problematic and this quickly became public knowledge; sometimes workarounds or patches for the patches are circulated within hours.

Background reading

Tuesday, July 15th, 2014, 8:30 am

Lawyers Who Don’t Use Encryption When Suing Government Entities With Access to Intercepted Material (Mass Surveillance)

And why every law school should teach everyone about encryption before any other “IT skills”

Industry

THERE IS a disturbing trend which is shared among pretty much all lawyers and other ‘legal’ professionals. I know because I checked. I also know because I saw how my friend, Pamela Jones (the paralegal behind Groklaw), got spooked by the spooks and stopped writing online after she had rejected my offer to use encryption about 8 years ago (saying it would only attract more attention). These are smart people who seem to be ignoring the threat of surveillance even when the threat is out there in the open, thanks to people like Edward Snowden. A lot of what Snowden showed had been known to me for years, but now there is undeniable truth which even the NSA’s chronic lies cannot cover up and shed uncertainty on. Ignorance is no longer a valid excuse.

I currently have a very strong case against a decision from the British government. I am sure I’ll win, the only question is when and at what cost (I have already spent thousands of pounds on it). I am not going to elaborate on it until the case is over, whereupon I will also release sensibly redacted papers (removing personal information) and explain the abuses which I have become aware of and personally suffered from. These abuses have impacted at least 4 people that my solicitor alone (an activist against torture) is working with. Nationwide, therefore, there may be thousands of such victims. It’s hard to say for sure how widespread this type of abuse has become, but one can estimate by extrapolation. In the future I will also file a formal complaint about it, then pressure my Member of Parliament to take action (not just yet).

Now, let’s deal with the key issue — or ‘beef’ — of this post. As in any legal case, papers are being sent back and forth, often electronically. It’s a practical thing to do because of speed (instantaneous for images and text). The stuff which the solicitor and I have already exchanged over E-mail is known about to the respondent, which has copies (this includes a request for appeal). Some stuff does not necessarily need to stay under the table, especially when it is accessible to both sides. Just as one requires no anonymity when purchasing a flight ticket (because the ticket itself already eliminates any chances of anonymity), for some documents it is fine to be visible to the opponent. There is not much to lose there.

But then there’s more sensitive stuff, like strategy.

Lawyers and barristers should always send sensitive stuff encrypted and sent over securely (to secure client-solicitor privacy/privileges). E-mail is one of the least secure methods of transferring data. It’s almost as thought it was designed for surveillance and profiling/linking people, but in reality it just got exploited by spooks and the protocols never adapted to counter these inherent deficiencies (encrypted mail still exposes the identity of the sender and recipient/s). Face-to-face or snail mail are better because bugging is hard and in the latter case it’s hard to achieve un-obtrusively, e.g. opening envelopes and re-sealing them. Since GCHQ and some government departments (e.g. Home Office) work together on increasing surveillance, right now under the guise of ‘emergency’ as if we’re in wartime, we can assume — pessimistically — that they may be studying the cases against them based on interception and preparing themselves based on this prior knowledge, or increased awareness. This is of course not acceptable, but then again, we already know that obeying the law is not our government’s best strength. That’s a debate for another day. In another circumstance one could probably chat or write about these issues (I know that my solicitor too advocates human rights at some capacity), but this is not the subject of this post.

As one who write prolifically on issues of national security, I have good reasons to suspect I have no privacy, unless technical measures are taken to protect it. I encrypt mail where possible. But I depend on others doing the same. Encryption is not a one-end preference, it needs to be agreed on and embraced by both ends.

People don’t want to jeopardise a case by unnecessarily giving away strategic arguments to the opposing side; I have seen people (usually in the US, some of whom I know online) on whom subversive means were used (illegal actions by those in power) to intimidate, harass, libel, etc. Completely bogus charges can be made up and hyped up in the media, framing of a person is very common (digitally too), and drainage of one’s resources through legal fees is also a common tactic of vendetta.

Any solicitor who wants to take on the government of his/her country absolutely must learn to encrypt. But this should not be limited to cases like these. Several months ago it turned out that the US government had spied on a US law firm which was working to advise a foreign nation on trade negotiations (this is a corporate matter). We know these types of abuses do happen in the West, so lawyers must learn to protect themselves. Unless they can sue to stop these practices (illegal actions by their government), they will need to adopt technical means of overcoming these dangers.

Perhaps I have become too cynical or too pessimistic when it comes to my government obeying the rule of law, but based on some recent revelations, the record supports me. We are living at times of lawlessness for the rich and powerful and oppression (through tyrannical laws and overreach) for the rest.

Sunday, June 29th, 2014, 8:34 am

The Darker Side of the Three Towers and RMG

RMG

USUALLY, the Three Towers are a good place to be. The residents are quiet, the place is relatively clean, but RMG tends to neglect it, leaving the gates, for example, unfixed for years.

It is also very hard to communicate with RMG, which refuses to provide basic information and impressively enough offers zero cooperation in case of serious incidents.

RMG is ruining what could otherwise be decent. The utility company (with a monopoly on the service) is apparently connected to the building’s operator (an incestuous relationship), so a form of corruption is likely, too.

Today I wish to deal with more serious matters and put them out there for our own safety, as well as to warn others.

Crime in our building recently took place, but RMG seems apathetic and unresponsive about it. I don’t believe we were personally targeted, but just in case something happens, I believe RMG should be held partly accountable or at least liable. No company should follow the example of RMG.

I am hereby, with some hesitation, writing regarding a very serious matter which seemed more serious after the police had reported gunshots near our apartment in Christabel (this was confirmed by the police in a letter).

The gunshots happened a short while after my wife was assaulted inside our building, Christabel. Two young boys stalked her in the elevator and then followed her into the bin room. When she entered they locked her inside and propped the door locked with a broom. She yelled for help and a nearby neighbour came to the ground floor and scared the boys away, after they had admitted (to him) they did not even live in the building. How did these boys get inside?

My wife was horrified, but this was never investigated. RMG did not even bother looking at the CCTV footage that it had captured. What is CCTV good for if one can’t be bothered to even use it? The individuals probably cannot be identified, but the way in which they infiltrated the building matters. RMG does not seem to care. Yes, they let it slide.

A couple of hours later we both saw two dodgy-looking people in their 40s or 50s hanging about in a nearby apartments building (marionette) which are still waiting to be demolished. Their behaviour could be described as odd and we thought about calling the police though saying two people are “up to no good” is a spurious complaint (the police would not appreciate it). I had other menacing incidents like this in the past, but never a gunshot (domestic violence across the hall, intruder in my house, and the nearby building routinely had ambulances and police vans next to it).

At 11PM gunshot was fired at a window (the police confirms this) and the following morning the road below us was closed by the police with two vans, including TAU (special police unit in Manchester), parked at both ends. One of the guys we saw last night (one of the two dodgy-looking one) was carried to a police van in a wheelchair. The police does not say much about the incident except the gunshots. This is far from reassuring. We now feel unsafe even inside our house.

I demanded that RMG should investigate all these incidents and inform residents what exactly was happening. They failed to do so, so in my view they are now liable and I decided to spread the word about what happened in this area, holding accountable those who are not doing enough to protect the residents (we pay a lot of money for RNG to do so every year). There is a risk to life here and since intruders assaulted my wife inside the building we cannot tolerate this.

Cooperation with the police has proved useless in the past (in fact it put me at risk because the criminals then perceived me as their enemy), so I was approaching RMG first. RMG should have extensive CCTV footage inside the building and around it. Given the separation of just 4 hours between these events there is likelihood that they are related and one took place right inside Christabel. Why did RMG never investigate or even respond? Total neglect. Even criminal neglect.

I asked RMG not to share my identity with the police (it would most likely not help as much as a testimony to RMG).

I recently thought about buying a property here, but after these incidents I have other, less favourable plans.

People’s safety seems to be at stake, not just RMG’s reputation. For what it’s worth, avoid RMG, wherever they are. All they’re good at it collecting money annually.

Update: three hours after I published this post (on a Sunday even) RMG contacted me and said they had forwarded the case, well over a week after the CCTV footage got taken (the rotation of footage may mean that relevant footage might already be erased). It would not be unreasonable to suggest that this post had something to do with their late reactions.

Update #2 (30/6/2014: Today I was issued the following face-saving response:

Dear Dr Schestowitz,

Thank you for contacting RMG recently.

Unfortunately, our CCTV expires after 14 days and we are unable to access footage after this point. We are now unable to access any CCTV from 16th June or before.

Having spoken to the Property Manager, she has made us aware that was onsite, and visited apartment [redacted] the day after the reported assault, but was not at that point made aware of any allegations. At that point, Claire would’ve been able to access any CCTV footage required.

Additionally, if there are any future queries of this nature, we would strongly recommend that you contact us over the telephone rather than via email. Over the phone, we will be able to assist instantly.

Most importantly, if there are any further crimes at the property, you would need to contact the police as the first matter of course, especially considering the nature of the reported crime.

If you have any further queries, please don’t hesitate to contact us.

Thanks, and kind regards

It is regretful that CCTV footage was left to expire and response over E-mail was so slow, probably due to bureaucracy. I will keep this in mind in the future.

Thursday, June 12th, 2014, 9:55 am

EasyJet Turns Away People With Tickets

EasyJet

EASYJET is an airline that should be blacklisted. It’s not just overpriced and does not arrange seatings; today it shocked my family when it turned down pre-booked tickets, saying that the flight was “overbooked”. Yes, apparently even when you book a flight with EasyJet (whose broken Web site makes it virtually impossible to check in) the airline can refuse to let the passengers board the plane. Even bus services don’t do such stuff!

EasyJet might be the crappiest airlines ever to exist. How can they legally turn back passangers with ticket they purchased for a flight? Way to ruin one’s vacation.

Sunday, June 1st, 2014, 3:58 pm

A Weekend of Wrestling With PHP

YESTERDAY I ranted about PhpWiki, blaming PHP for the most part. Why? My Web host has ‘broken’ a lot of the software that I run in this Web site. Some software has relentlessly and happily been running for a decade or more. It is a lot of software (all in all about 20 databases), some of which I have manually patched or changed/hacked whenever the host upgraded PHP. It is a lot of work. It is a lot of inevitable maintenance. I blame PHP. The latest upgrade is to PHP 5.3. The host reverted back to the older version (5.2) for two weeks (a sort of an ultimatum) to help me sort things out before this upgrade is permanently imposed. PhpWiki was not the only cause of issues, but it was part of it that took a whole noon plus afternoon (almost as much time as it would take to just rebuilt it all manually). While I was able to (eventually) make a minor upgrade (from a 2006 version to a 2008 version, not to the current or even recent versions) it remains unclear why PHP decided to not be backward-compatible. It is a total nightmare for sites for have a lot of PHP code, especially if their maintainers are not full-time PHP developers or are ingratiating components of software which is no longer actively maintained. PHP is risky to choose or work with. I learned this the hard way. It may be normal for proprietary frameworks to do this, but why FOSS?

Today I successfully upgraded two PHP-Nuke sites (thankfully there were upgrade scripts which worked reasonably well) and then I struggled for a whole with Gallery 2, where the upgrade process is complicated and very long, resulting in a sub-optimal outcome (e.g. no thumbnails and no tolerance of a perfectly fine ImageMagick installation). People without very advanced knowledge of UNIX and other such skillsets won’t manage to keep their photo galleries up to date. This is a real travesty. This is the catalyst of ‘Web rot’.

What I’ve identified and am eager to summarise after two days of frustrating work is this:

  1. PHP-based software cannot be counted on, especially if it’s intended to run for years (the long run)
  2. Choosing less established PHP-based software is risky as it might cease being maintained
  3. cPanel does give access to PHP error logs, but this is not too trivial to find
  4. Internal server errors can be due to restrictive Web hosts who deny access to scripts based on their UNIX-style permissions
  5. It is always better to install software from front-end scripts, such as those found in Fantastico
  6. Don’t use too many pertinent bits of software; diversity can be a nightmare to deal with
  7. When patching existing software, keep a log/record of everything that has changed
  8. If a lot of people across the Web complain about upgraders, importers, exporters, etc. then it’s better not to bother with them at all as they won’t work correctly and just waste time
  9. Check carefully and exhaustively a good test set of data following upgrade, or missing data will only be identified several years down the line when backups are too hard to find and revert to (I just found out that this happened to me)
  10. Use static HTML where you deem it suitable because the cost of maintaining/upgrading PHP is often too high to justify such a reliance

I am fed up with PHP. One cannot just install something and let it run along for years. It’s a lot of work to maintain and sometimes there’s loss of data, induced by improper upgrade paths and mistakes/accidents.

Saturday, May 31st, 2014, 4:11 pm

PhpWiki is Obsolete and PHP is to Blame

TEN years ago (or more) I installed PhpWiki. I used it to manage communications with family and friends (privately), then to collaborate with colleagues (I had co-authored papers at the time, so needed to manage version changes) in a publicly-accessible installation (my second installation) of an up-to-date version of PhpWiki. It was up-to-date at the time, but not anymore. I later installed PhpWiki once again in iuron.com. It was the main CMS there (my only site to be managed primarily by PhpWiki).

PhpWiki is an important piece of software because it was the first public-available piece of software running a wiki using PHP. It goes back to 1999 when very few people knew what a wiki was. Its authors deserves big thanks for releasing it under the GPL.

I have found that some people — like myself — had their data ‘locked’/’trapped’ inside PhpWiki and as PHP is not backward-compatible they sought a way out (PhpWiki just stopped working with an upgrade of PHP). Various bits of wiki software offer importers of PhpWiki, but they don’t deal with the database directly, they require exporting of data (which earlier versions of PhpWiki don’t appear to have, except perhaps from the command line). Upgrading PhpWiki is hard because my host for this Web site offers no access to PHP log/error files and things do not work as expected. The only way to really view the Wiki data at the moment is through PHPMyAdmin. What a mess.

Having spent several hours wrestling with this issue of no upgrade and no export available (I checked numerous importers), I am left with no choice but to manually migrate the data to some other Wiki software. I have already set up FOSWiki and MediaWiki before, but I might be curious enough to try something ‘new’ (or exotic) like PmWiki, DokuWiki, WikkaWiki. The problem, however, is that they too might become deprecated/unmaintained one day in the future, leading to the same problem I am having right now.

PhpWiki is still being developed (just not frequently) and there are newer releases. I will always fondly remember the one Wiki software that I set up and used before people knew much about Wikis (except perhaps the example of WikiPedia). Here are some final screenshots of the Wikis that will soon go dark, despite the fact that I customised them a great deal and modified the code to suit my needs.

If only PHP was eager to keep old software functional (compatible with newer versions of PHP) this wouldn’t have happened. I still have several other CMSs to go through, trying to upgrade, hack, or export from. Why? Well, because a forced upgrade to PHP 5.3 will kill them. I mostly blame PHP here. It’s an applications killer. It didn’t have to end like this and I am not the first to complain about it.

PhpWiki

PhpWiki private

Real-time Posts



Retrieval statistics: 23 queries taking a total of 0.372 seconds • Please report low bandwidth using the feedback form
Original styles created by Ian Main (all acknowledgements) • PHP scripts and styles later modified by Roy Schestowitz • Help yourself to a GPL'd copy
|— Proudly powered by W o r d P r e s s — based on a heavily-hacked version 1.2.1 (Mingus) installation —|