Frank Leonhardt's Blog

Installing Apache 2.4 with PHP on FreeBSD for Drupal 8. It’s a Nightmare

I’ve been playing about the Drupal 8 (still in Beta) and one of its features is that it needs the latest version of PHP (5.5.9 or later). I have a server I keep for testing the latest whatever, and this includes Apache 2.4. So how hard can it be to compile in PHP?

Actually, it’s not straightforward. Apache 2.4 is fine, but PHP is another matter. First off, installing lang/php55 does not include mod_php for Apache. It’s not that the option to compile it hasn’t been set – the option has gone. With a bit of digging around you can find it elsewhere – in www/mod_php55. Don’t be fooled in to thinking you need to just build and install that though…

You’ll probably end up with stuff like this in your httpd error log:

Call to undefined function session_name() Call to undefined function hash()

Digging further you’ll find www/php55-session and security/php55-hash in there, and go off to build those too. Then wonder why it still isn’t working.

The clue can be found with this log file error:

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212-zts/session.so' - Cannot open &quote;/usr/local/lib/php/20121212-zts/session.so&quote; in Unknown on line 0

(NB. The &quote appears in the log file itself!)

Basically, mod_php expects you to compile the ZTS (Zend Thread Safe) version of everything. And why wouldn’t you? Well it turns out that this important option is actually turned off by default so you need to configure the build to include it. Any extensions you’ve compiled up until now will not have been placed in a directory tagged with -zts, which is why it’s looking in the wrong place as shown by the error log.

If you’re reading this following a Google search, you’ve probably already fallen down the Pooh trap. You need to go back to lang/php55 and start again with the correct options. The best way to do this (in case you didn’t know) is:

make clean make config make make install

When you run make config it’ll give you a chance to select ZTS, so do it.

Repeat this for compiling www/mod_php55 and then go back and compile www/php55-session, security/php55-hash and anything else you got wrong the first time, You don’t have the option to configured them, but they must be compiled again once the core of PHP has been compiled using ZTS.

Incidentally, if you haven’t had this pain before, you will probably need to switch to using the new pkg system if you haven’t already. Trying to build without it, it’ll put up a curt little note about it and go in to sulk mode until you do. Unfortunately, on an older FreeBSD, any attempt to compile this will result in an O_CLOEXEC symbol undefined error in pkg.c. This is actually a flag to the open() kernel function that was added to POSIX in 2008. What it means is that if your process subsequently makes exec call, the file handle will be automatically closed. It saves leaking fds if your execution path goes awry. But what’s the solution?

Well, if you’re using an older version of the kernel then it won’t support O_CLOEXEC anyway, so my fix is to delete it from the source and try again. It only appears once, and if the code is so sloppy that it doesn’t close the handle, it’s not the end of the world. The official answer is, of course, to upgrade your kernel.

If you are running Drupal 8, here’s a complete list of the ports you’ll need to compile:

lang/php55 (select ZTS option in the configuration dialogue)
www/mod_php55 (select ZTS option in the configuration dialogue)
www/php55-session
security/php55-hash
security/php55-filter
devel/php55-json
devel/php55-tokenizer (for Drupal 8)
databases/php55-pdo
databases/php55-pdo_mysql
textproc/php55-ctype
textproc/php55-dom
textproc/php55-simplexml
graphics/php55-gd
converters/php55-mbstring (not tested during setup)

All good fun! This relates to Drupal 8.0.0 RC1 – it may be different with the final release, of course.

6-October-156-October-15

Safe Harbour Agreement on Data Sharing with Uncle Sam ruled unlawful

Photo Source: Court of Justice of the European Union — Causing trouble – Court of Justice of the European Union

The long awaited ruling about whether the Safe Harbour agreement allowing free transfer of data concerning European citizens to the USA is valid under European Law has just been published. And it’s a doozie.

Basically a Safe Harbour agreement (note the use of the indefinite article here) means that you won’t be sent down the river for doing something that might otherwise be illegal. The specific Safe Harbour agreement in this case (2000/520/EC) says it’s okay for European data controllers to send whatever they like to the American’s because Uncle Sam is a good friend. This would otherwise be a no-no because you’d be giving up control over information that would otherwise be protected by European privacy laws.

This situation is currently being misrepresented in the popular press as being about Facebook (social media being their favourite subject after themselves); it’s not. It’s about all data. The case was brought by Austrian civil rights campaigner, Max Schrems in the Irish courts to test the legality of Facebook doing just this, as a high-profile example. A lot of American companies like to base their data centres in Dublin because, up until now, the Irish courts have been quite relaxed about what goes in compared with certain other European governments. (And lets not forget the tax breaks, and that Dublin is a nice place to be).

Hanging over this is the shadow of Edward Snowden (yet again), raising public awareness and anxiety over government access to PII. The fact that this PII is already in the hands of the likes of Facebook, Amazon, Microsoft, Google and Twitter with the full knowledge of the subjects doesn’t seem to matter – it’s the principle of the thing!

Anyway, the ruling basically says that the initial ruling is incompatible with European Law, and we can’t trust the Yankees to look after it without further safeguards. Where this leaves American companies with European data centres remains to be seen.

5-October-1522-October-15

Edward Snowden says smartphones can be taken over by text message

The most incredible revelation has just appeared on the BBC News web site. Apparently Edward Snowdon has revealed in a Panorama interview that smartphones can be taken over by sending them an SMS.

“The former intelligence contractor told the BBC’s Panorama that UK intelligence agency GCHQ had the power to hack into phones without their owners’ knowledge.” it begins. It continues with “Mr Snowden said GCHQ could gain access to a handset by sending it an encrypted text message and use it for such things as taking pictures and listening in.”

That’s pretty specific, and as I said, incredible. For anyone with a shaky knowledge for the English language, “incredible” means difficult or impossible to believe. If it were true, then one of the following must also be true:

All the handset makers in the world would have to pre-install a wedge to intercept SMS traffic before the OS got to the hardware.
Apple would have to be in on it; and there would have to be something hidden in the publicly available Android source code that no one had noticed.
All the hardware used in smartphones would have the ability to intercept SMS and implement a hypervisor to manipulate the OS in way I can’t even comprehend (and with the chip maker’s collusion.

None of the above strikes me as very likely, so if there is any truth in it, what could it be?

The obvious answer is that GCHQ and the NSA have some dodgy Apps which, if you install them and give them permission, could do things on receipt of a SMS. Not such a big deal – criminals are doing this and I’d be surprised if governments weren’t in on that game too. He could also be referring to known exploits in some phone OSs that could be used to compromise its security. But the BBC quote is clear that this is something “new”, and applies to all, or at least the majority of smartphones. It does not say “some handsets”; the implication is clearly that all handsets can be pwned by the spooks whenever they want. I’ve kept the text of the original article, as I suspect they’ll be needing to change it!

It could also be that Mr Snowden is being grossly mis-represented in a case of sloppy journalism, or in a deliberate attempt to hype the forthcoming Panorama program. The term “encrypted text message” rings an alarm bell here; no one who knew anything about the subject would have used the word “encrypted” to refer to a specially crafted or encoded message.

Or it could be that the publicity-seeking Mr Snowdon has sold some credulous hacks a fairy story and they’ve lapped it up.

5-October-155-October-15

Malware sent in .ace format

This one made me look twice. I’m intercepting a lot of malware spreading attempts with text that starts out thus:

Dear Sir or madam
 Hi
 I'm milad and our company called UTIACHEM CO. located in Tehran-Iran.
 Following a telephone conversation with my colleague.
 I was going to send me your request.
 We have an inquiry from your products as attached file,please check.
 Please answer each request.
 Please certificate and an analysis and data sheet product send it to us.

They’re notable because they contain a pair of files of similar length (454K) which have names ending in .jpg.ace. It took me a while to figure this out; they’re compressed using a program called WinAce, a proprietary (paid for) German program from the late 1990’s. The only people likely to have a copy of this will likely be running Windows 98 – or so I thought. The company is still going, much to my surprise, and there are Linux and Mac versions too – although not UNIX, BSD, Android, Apple OS or anything else you’d need if you wanted to compete as a cross-platform archive format. There is, however, a DLL for unpacking that may be used in other people’s products, so perhaps decoders are more prevalent than might first appear.

I wonder how many they’ll have to spam out before they find someone (a) with an ACE decoder; and (b) dumb enough to use it?

Incidentally, most of these spams trace back to Mandril (aka Mailchimp), and are probably uploaded there by someone abusing an IOMart account (from Nottingham). In other words, zero abuse enforcement, based on previous attempts to contact them.

5-October-157-October-15

iZettle is now contactless on Android

Update 6th October 2015:

What a difference a day makes! Yesterday I was trying to get iZettle 3.0.0 working on my Android 5.0 handset and failing miserably. Today, it’s all working just fine. The difference? Three things:

Don’t have the handset and the reader too close together. Bluetooth was interfering with the WiFi. They’re on the same frequency, and Bluetooth doesn’t really play nice with 802.11n. While the Internet connection was being blocked by the reader, the App became unstable on loading.
Either turn on the reader before you start the App, or afterwards. I’m not completely sure of the timing, but there seems to be a bad spot if they’re both starting up together where they fail to sync and both go funky deux. The photographs following the review show what I mean!
When you turn on the reader, wait for the “Please wait….” to disappear before you considering it to be “on”. i.e. don’t start the App while it’s in that state, and don’t do anything to try to use it if the App is already running.

If you follow the rules above, everything else works like a charm. And like all rules, there are exceptions when it might work anyway.

Review

iZettle is a Swedish company, founded in 2010, offering a complete mobile card payment system for small businesses with Terms of Business and charges that should make the bankers blush. The deal is that they charge a straight ~1.5%-3% dependent on volume, with no minimum transaction fee. You can buy a reader from them, or if your volumes are high enough, they’ll give you a free Chip and Pin reader that connects to some smartphone/tablet hardware (iPhones and a few Android devices) using the microphone/speaker. My advice on the free reader is “don’t be cheap – pay for the bluetooth one”.

Today iZettle released its all-new Android App, version 3.0.0, which allows it to work with the Card Reader Pro Contactless . When I say “released”, it appeared in the Google Play store without fanfare; not even a press release. Apple fanbois have been able to use contactless cards (and Apple Pray) for some time now, but the Android App has always lagged behind; odd, as 90% of smartphones run Android. Perhaps iZettle really likes Objective ‘C’?

The good news, apart from contactless support, is that the new Android App is much cleaner and nicer to use than the old one. On startup, it goes straight in to the screen where all you need do is enter the amount and optional description and add it to a cart (you can’t charge it immediately, for some reason). If you have pre-set items you can access them in grid or list from by swiping left; tapping an item adds it to the cart.

70D_04547c

To take a payment just tap on the cart icon. You get a chance to add a percentage or set value discount and when you’re done it just connects to the card reader and does the business. One very welcome feature is that the display on the reader now shows the amount being charged.

There are other good features lying about in the software. For example, a battery status indication is available in settings. But the main feature of 3.0 is its ease of use.

Teething problems connecting notwithstanding, there are a few possible improvements that spring to mind. It would be handy to be able to enter a number and select “Charge” immediately without going through the cart first. This may be a bug – before you enter an amount the there is a large button marked “Charge” that changes to “Add Item” (to the cart) as soon as you enter something. Also, there are pre-set discount rates of 5%, 10% and 15% and the ability to enter any percentage manually, but you can’t edit the pre-sets. More seriously, you can’t edit the VAT rate table or enter a manual rate. It has 0%, 5% and 20%, which are the current rates in the UK, but they’re going to change. It also makes no differentiation between Zero-rate an Exempt, which does matter for proper accounting.

But these are minor quibbles. iZettle 3.0 is a big improvement on the rather clunky 2.5 and I’ve no doubt the teething troubles with the connection will be fixed. In the mean time, just leave the reader enough time to warm up.

In view of the problems I did have, a means of rolling back updates is needed. iZettle says that they can’t do this at the moment, but given the difficulty of testing Apps – especially Android ones – on the wide range of hardware and OS versions out there, relying on a compatibility list is a bad idea tactically. There’s a danger that people will seek to download older versions of the App if they encounter problems, and a bit of research this morning turned up a few .apk files on the Internet that had definitely been tampered with. I’m trying to persuade iZettle to implement a rollback option but no luck yet.

Rogues gallery: iZettle 3.0.0 going mad yesterday. See update above.

If you get the timing wrong or something interferes with the Internet connection (e.g. it’s masked by bluetooth) you could be in for a world of pain.

70d_04521

Whenever I try to make a charge it either says that an “Unexpected error occurred – try again”, or it crashes out.

70D_04543

This is before it even gets to the “insert card” part. And it’s really flaky when it comes to keeping bluetooth contact with the reader.
70D_04533 70D_04542

It randomly freezes, in the case of the above while it was moving between screens – it appears to be when its thinking about bluetooth connections.

It even manages to crash the reader itself!

70D_04540

For what it’s worth, I’m using Android 5.0, and it worked just fine (albeit Chip and Pin) on the old version of the App.

Fortunately I don’t process a lot of payments, so can live without it but others may be having a really bad day as a result.

23-September-15

Fake Received: used by spammers – new tactic

Actually, this isn’t a new tactic at all. There was a lot of this going on in the 1990s and early 2000s, but I haven’t seen such widespread use of fake Received headers for a while now. As mail is no longer relayed, what’s the point? And yet, it’s coming again. Take this recent example:

Received: from host101-187-static.229-95-b.business.telecomitalia.it (host101-187-static.229-95-b.business.telecomitalia.it [95.229.187.101]) by real-mail-server.example.com (8.14.4/8.14.4) with ESMTP id t8NAOpJS007947; Wed, 23 Sep 2015 11:24:57 +0100 (BST) (envelope-from name-up-name@a-genuine-domain.com) Received: from remacdmzma03.rbs.com (mail09.rbs.com [155.136.80.33]) by mail.example.com (Postfix) with ESMTP id B849451943 for made-up-name@example.com; Wed, 23 Sep 2015 11:22:43 GMT) Message-ID: <XZ95O517.6281609@rbs.co.uk> Date: Wed, 23 Sep 2015 11:22:43 GMT Thread-Topic: Emailing: bankfl.emt Thread-Index: made-up-name@example.com From: "RBS" <secure.message@rbs.co.uk> To: made-up-name@example.com MIME-Version: 1.0 To: made-up-name@example.com Subject: Bankline ROI - Password Re-activation Form Content-Type: multipart/mixed; boundary="----------------_=_NextPart_001_01CF5EDB.A2094B20" This is a multi-part message in MIME format. ------------------_=_NextPart_001_01CF5EDB.A2094B20 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit
Please find the Re-activation form attached, send one per user ensuring only one box is selected in section 3. A signatory on the bank mandate must sign the form.
… etc …

Obviously the above has been re-written to use example.com, and the made-up-name was something random. The rest of the header is as it was. They’re obviously trying to convince you that your mail servers have already seen this this message, so it must be okay. This is such a dumb trick – does any spam filter bother to even look at earlier headers? Are they hoping that Bayesian analysis will score the incorrectly guessed mail server as particularly hammy?

But what’s doing this, and why? Is there a new spambot in town, or is there a new spam filter that’s susceptible to such a dumb trick?

As it stands, this was sent from a blacklisted IP address and the SPF fails for RBS anyway, and the English it was written by a virtual English illiterate. For what it’s worth, the payload was malware in a ZIP.

15-September-1515-September-15

Tomorrow, Apple will break iZettle ApplePay readers with iOS update

I just heard from iZettle about a rather unfortunate feature of the iOS 9.0 upgrade that Apple will be dumping on its fanbois tomorrow: it doesn’t work. No, I mean it really doesn’t work. There’s a bug that stops it pairing with some Bluetooth devices, including iZettle card readers.

If you’re the kind who has to have the latest iPhone or fondleslab then you’re going to have it set to auto-update. Bad luck. Will you take a cheque?

10-September-1515-September-15

Always download software updates. HM Government says.

I saw a poster on the tube. A cartoon cat held a smartphone showing a message “Your whole life is in here. Is it secure?” With a software update button below it. Interesting, I thought. Was someone selling protection from rogue software updates? As everyone knows, these have a habit of ruining your day. No. It was part of a government campaign. To back up your data, especially before updating software perhaps? No!
It was actually encouraging lusers to the install updated software over the Internet as often as possible. So you can now blame HMG for what Windows 10 has done to your PC or Apple does to your iPhone next week.
Don’t laugh, it’s your taxes paying the bill.

10-September-159-May-17

People are very wrong about Jeremy Corbyn

I was speaking to a Conservative party activist of my acquaintance a couple of weeks ago. He was rubbing his hands with the thought of Jeremy Corbyn being the new front-runner to lead the Labour party. Listening to the comment on Sky News this morning, it’s now being considered a foregone conclusion, with supporters of the other three candidates putting on a brave face and deflecting questions along the lines of “Will Labour ever be electable with Corbyn in charge”?

Early on in the campaign, Tony Blair put the problem rather well – if the public had rejected Ed Milliband’s Labour party because it was too left-wing, why would they prefer an even more left-wing party lead by Corbyn?

They’re all missing the point (no surprise where Blair is concerned). Given the right circumstances the British Public will definitely vote for a left-wing nut job with a deluded grasp of economics and a track record of courting publicity using international untouchables. London voted for Ken Livingstone. Twice. In spite of the consequences. Not because they approved of his policies (or even understood them), but because he was likeable, and because he was the person most likely to annoy the incumbent government in Westminster at the time.

Jeremy Corbyn has a very good chance of winning the Labour Leadership for the same reasons as Livingstone managed to cling on to power. Whilst I disagree with his economics, foreign policy and most of the other stuff he espouses, I get the feeling he’s a nice guy personally – I’d prefer to spend my time with him than any of his New Labour opponents.

Will this be enough to carry him to the job of Prime Minister in 2020? Flying in the face of the rest of the world, it seems, I have to say its possible. This is not a good thing. It might be fun, but the matter is too serious.

Labour’s enemies stuffing ballots with £3 votes should be very careful what they wish for.

7-September-1515-October-15

GMail can’t send to sendmail

Gmail Fail

What’s happening with Google? Their Internet engineering used to be spot on. They’re generally a bunch of clever guys, and they follow standards and their stuff just works. Or did. Lately their halo has been getting a bit tarnished, and problems with GMail are a good case in point.

It all started quietly around a month ago on the 6th August. About a week later, people started complaining that users sending mail to them from GMail were getting bounce messages. It looks like Google had rolled out a broken software update, but they’re keeping a low profile on the subject.

After a great deal of investigation it appeared that their new MTA was attempting to make a STARTTLS connection when delivering mail on port 25. STARTTLS is a mechanism that allows encryption on a standard unencrypted channel. Basically, the sender tries a STARTTLS command and if the receiver supports it, returns a reply of “okay” and the remainder of the connection is encrypted using TLS. unfortunately Google’s implementation, which had been working for years, is now broken. The GMail lusers got a bounce back a week later that said it couldn’t negotiate a STARTTLS connection. No further explanation has been forthcoming. STARTTLS should work, and if it doesn’t GMail should try again without using it, but doesn’t.

On the servers I’ve examined there is no problem with STARTTLS. Other MTAs are continuing to use it. All certificate diagnostics pass. Presumably Google has changed the specification as to what kind of TLS/SSL its going to work with, as, presumably, it’s not happy working with all types. Not all servers have this problem. But Google isn’t telling anyone what they’ve done, at least not so far. Working out what’s wrong with their new specification using trial and error takes a while, and I have yet to find a combination that works. And besides, it’s not Google’s place to tell recipients what kind of encryption they should be using, especially when the default state is unencrypted.

Google does offer a troubleshooter but it doesn’t cover this eventuality. There is an option to report other problems, but to date I’ve had no response.

So what’s the solution? The only method I’ve found that works is to disable STARTTLS on Port 25. This means that Google can’t try and fail, and go in to sulk mode. And here’s the bit you’ve probably been waiting for: how to do it.

Assuming you have an access DB configured for sendmail, (the norm) you need to add an extra line somewhere and makemap it:

srv_features: S

On FreeBSD this file is /etc/mail/access and you can make it active using make run from the /etc/mail directory. But you probably knew that.

The srv_features stuff basically tells sendmail which services to advertise as being available. STARTTLS is option ‘S’, with a lower-case letter meaning “advertise it”, and an upper-case meaning “don’t advertise it”. This over-rides defaults, and all we want to do here is stop advertising STARTTLS. If it’s not advertised, Google doesn’t try using it (at least for now).

You might want to read this sendmail documentation for more information in the normal Sendmail easy-to-understand(!) format. If that doesn’t do it for you, look at section 5.1.4.15 of the manual, available in PDF here.

Now Google may defend this state of affairs by saying that they’re implementing something odd with STARTTLS for “security reasons”. There may even be some justification in this. If I knew what they’d changed I might be able to comment on that, but I can’t. However, even if this was the case, they’d be wrong in principle. Since the dawn of Internet email we’ve had RFCs telling us how things should work. You can’t just change the way you do things and expect everyone else to change to suit you, however large you are. And it’s possible that what Google has done is RFC compliant, even if it is bonkers. There are unspecified aspects in RFCs, and some grey areas. However, anyone who’s been around for long enough will know that Sendmail is the de-facto MTA. If you have an argument about the interpretation of an RFC, you can settle it by asking the question “Does it work with sendmail?” If it doesn’t, it’s your problem.

And while we’re at it, it’s really good of Google to stop anyone reading your email while it’s in transit (could they be thinking of the NSA here?) After all, you don’t want email sent through GMail to be readable by anyone until they’re delivered, do you? The only snag is that they are still being read and analysed, by Google. Of course. Email is never secure unless you have end-to-end encryption, and by definition, you can’t get this with a webmail service.