Odd dependency on Google Chrome

For weeks I have had problems with Google Chrome. It would work very few times and then for reasons I didn’t understand, would stop working. On the command line you would get several screens of text, but never would the Chrome window appear.

So I tried the Beta, and it worked… once.

Deleted all the cache and configuration and it worked… once.

Every time the process would be in an infinite loop listening to a Unix socket (fd 7) but no window for the second and subsequent starts of Chrome.

By sheer luck in the screenfulls of spam I noticed this:

Gkr-Message: 21:07:10.883: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files

Hmm, so I noticed every time I started a fresh new Chrome, I logged into my Google account. So, once again clearing things I started Chrome, didn’t login and closed and reopened.  I had Chrome running the second time! Alas, not with all the stuff synchronised.

An issue for Mailspring put me onto the right path. installing gnome-keyring (or the dependencies p11-kit and gnome-keyring-pkcs11) fixed Chrome.

So if Chrome starts but you get no window, especially if you use cinnamon, try that trick.

 

 

Securing WordPress with AppArmor

WordPress is a very popular CMS. According to one report, 30% of websites use WordPress, which is an impressive feat.

Despite this popularity, WordPress is built upon PHP which is often lacking in the security department. Add to this that the user that runs the webserver often has a fair bit of access and there is no distinguishing between the webserver code and the WordPress code and you set yourself up for troubles.

So, let’s introduce something that not only can tell the difference between Apache running and WordPress running under it, but also limit what WordPress can access.

As the AppArmor wiki says “AppArmor is Mandatory Access Control (MAC) like security system for Linux. AppArmor confines individual programs to a set of files, capabilities, network access and rlimits…”.  AppArmor also has this concept of hats, so your webserver code (e.g. apache) can be one hat with one policy but the WordPress PHP code has another hat and therefore another policy. For some reason, AppArmor calls a policy a profile, so wherever you see profile translate that to policy.

The idea here is to limit what WordPress can access down to the files and directories it needs, and nothing more. What follows is how I have setup my system but you may need to tweak it, especially for some plugins.

Read more Securing WordPress with AppArmor

WordPress 4.9.1

After a much longer than expected break due to moving and the resulting lack of Internet, plus WordPress releasing a package with a non-free file, the Debian package for WordPress 4.9.1 has been uploaded!

WordPress 4.9 has a number of improvements, especially around the customiser components so that looked pretty slick. The editor for the customiser now has a series of linters what will warn if you write something bad, which is a very good thing! Unfortunately the Javascript linter is jshint which uses a non-free license which that team is attempting to fix.  I have also reported the problem to WordPress upstream to have a look at.

While this was all going on, there were 4 security issues found in WordPress which resulted in the 4.9.1 release.

Finally I got the time to look into the jshint problem and Internet to actually download the upstream files and upload the Debian packages. So version 4.9.1-1 of the packages have now been uploaded and should be in the mirrors soon.  I’ll start looking at the 4.9.1 patches to see what is relevant for Stretch and Jessie.

Short Delay with WordPress 4.9

You may have heard WordPress 4.9 is out. While this seems a good improvement over 4.8, it has a new editor that uses codemirror.  So what’s the problem? Well, inside codemirror is jshint and this has that idiotic no evil license. I think this was added in by WordPress, not codemirror itself.

So basically WordPress 4.9 has a file, or actually a tiny part of a file that is non-free.  I’ll now have to delay the update of WordPress to hack that piece out, which probably means removing the javascript linter. Not ideal but that’s the way things go.