This week I finally took the plunge and upgraded most of the servers I work with from PHP 7.1 to PHP 7.2. (Some of them still can't be brought forward due to dependencies that use mcrypt.) I ran into a few snags with the upgrade to 7.2 and thought I'd document them here. This may be useful if you:

• Run CentOS Linux 6.x (6.9 in my case),
• Want to install PHP 7.2,
• Need pthreads support in PHP, and
• Prefer to compile PHP from source

Executive summary

In order to build PHP 7.2 with pthreads on CentOS 6, you must upgrade to autoconf 2.64, which must be done manually instead of via the yum package manager. You'll also have to first build PHP 7.2 without pthreads, then use this "bootstrap" copy to prepare the pthreads extension before compiling PHP a second time.

autoconf 2.64

Start by installing autoconf 2.64. The latest version available through yum is 2.63, which isn't sufficient to build PHP's configure script.

It's critical that you supply the --prefix=/usr option when ...

I hate when a redesign gets in the way of a good thing.

Zap2it.com has been my choice for TV listings for many years. They briefly rebranded as "Screener" in 2016, with a new domain that broke my bookmarks and a bright yellow theme that broke my eyeballs. That venture didn't go very far; the Zap2it name returned after a few months, at which point I updated my TV listings bookmark (again) and went on with my life.

Tonight I went to see what's on TV and my trusty bookmark took me to a 404 page. Compounding matters, visiting the main Zap2it.com page showed me a totally blank "TV Listings Grid" section. This is the unfortunate hallmark of a website that won't work properly if LocalStorage is disabled.

I normally keep LocalStorage turned off, because it presents a bundle of privacy issues and I've found that the simplest w...

Today Bert Huber from PowerDNS announced a new DNS-based geolocation service. Given an IP, it returns the corresponding latitude and longitude coordinates. Using it is simple; to look up the coordinates for IP address 1.2.3.4, just reverse the octets and query the TXT record for 4.3.2.1.geo.lua.powerdns.org. I don't see any official details from PowerDNS yet, just Bert's tweet, but based on the domain, the service appears to be using PowerDNS' Lua capabilities.

The usual caveats about geolocation apply:

$ dig +short TXT 73.52.93.172.geo.lua.powerdns.org
"33.745800 -117.826202"

Despite that server living in Dallas, the coordinates that come back are for Tustin, CA. That's because the ARIN allocation for 172.93.48.0/21 points to a corporate address in Tu...

If your copy of Firefox has been behaving oddly but you can't figure out why, you might want to check the value of your privacy.resistFingerprinting preference.

Starting around Firefox 41, a setting called privacy.resistFingerprinting was introduced. This option didn't get much fanfare until the release of Firefox 55, when Mozilla announced a litany of features they'd be retrofitting into mainline Firefox from the Tor browser bundle. I decided to enable privacy.resistFingerprinting in Firefox 56, hoping this preference might obviate the need for one or more of the privacy extensions I use.

After a few days I forgot all about toggling that option. Meanwhile, Firefox had begun acting strangely:

• Some sites using Flash were telling me I didn't have Flash installed, despite being in my Flashblock whitelist.

• Some sites had miscellaneous elements that stopped functioning properly.

• When I started or restarted Firefox, it came up windowed instead of maximized, even after verifying that `xuls...

For the past few days I've been ignoring upgrade errors from harfbuzz, and this morning I finally found time to track things down. The first step was to figure out what the heck "harfbuzz" is, and why it's installed. Turns out it's a glyph generator; on my FreeBSD systems, it's ultimately a dependency of rrdtool.

Trying to update the installed harfbuzz-1.5.1_1 port to the new harfbuzz-1.7.2 release was kicking back errors like this:

Traceback (most recent call last):
  File "/usr/local/bin/g-ir-scanner", line 65, in <module>
    from giscanner.scannermain import scanner_main
  File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", line 41, in <module>
    from giscanner.dumper import compile_introspection_binary
  File "/usr/local/lib/gobject-introspection/giscanner/dumper.py", line 34, in <module>
    from .gdumpparser import IntrospectionBinary
  File "/usr/local/lib/gobject-introspection/giscanner/gdumpparser.py", li...

Back in 1999, when many of us still got a new IP address every time we dialed into the internet, I set up ipid as an easy way to figure out my public IP. It caught on, and was eventually added into several dynamic DNS clients and various other projects with a need to determine the user's IP. I took the service down in 2013, given the myriad other options available; you can just Google "IP address" to get it, now.

Recently I was debugging a DNS issue and was surprised to see how many queries were still coming in for the ipid name. I decided to spin the site back up on a spare VPS and see what sort of traffic it would get. I wasn't quite expecting this:

Server uptime: 14 hours 17 minutes 12 seconds
Server load: 0.01 0.02 0.00
Total accesses: 8149452 - Total Traffic: 101.4 MB
158 requests/sec - 2067 B/second - 13 B/request

~160 hits per second to a site that's been down (and NXDOMAIN) for 4 years! There's obvio...

Yesterday, Scott Arciszewski from ParagonIE published The 2018 Guide to Building Secure PHP Software. If you develop for (or attack) the web in any language, this is an excellent reference that addresses a number of common web application pitfalls.

In the section devoted to security headers, I saw a reference to one that's flown under my radar until now: Expect-CT. Scott Helme has a nice write-up of Expect-CT, and I went off to read the specification for myself. As it happens, the HTTP Working Group just posted an updated draft today, but the changes aren't substantive.

The executive summary of Expect-CT is that Chrome can no...

Today I spotted an entry in the firewall log that's sent me down a bit of a rabbit hole. I default-deny traffic between my different network segments, and I filter most of the mundane stuff before it's logged, so this caught my eye:

    Deny UDP 169.254.5.108:17784 255.255.255.255:17784 in via dc1

Apparently port 17784 is the default port for the Universal Discovery & Access Protocol, or UDAP, a network protocol so obscure it doesn't even have a Wikipedia page. UDAP seems to be spoken mostly by LG smart TVs (UDAP originated at LG, as far as I can tell) and by a now-defunct home audio streaming product called a SqueezeBox. I don't own any of this equipment, so naturally I was curious what device the packet came from.

After running tcpdump for a couple of minutes, I came up with enough multicast packets from 169.254.5.108 to at least figu...

This week, the Plugin Vulnerabilities site posted about a local file inclusion exploit in MailChimp's WordPress plugin for WooCommerce. My thoughts about WordPress are generally unenthusiastic, so I don't spend much time looking at its vulnerabilities, but from the standpoint of a mail server operator I was interested in the MailChimp angle. As it turns out, there's nothing of impact to mail admins, though I was a little intrigued by MailChimp's fix.

The exploit, in a nutshell, is that one of the plugin's scripts accepted a template name via the query string and then called include() on a filename built from that variable:

<?php if(isset($_GET['error_notice']) 
  && file_exists(__DIR__.'/errors/'.$_GET['error_notice'].'.php')): ?>
    <?php include(__DIR__.'/errors/'.$_GET['error_notice'].'.php'); ?>
<?php endif; ?>

Direct us...

On a relatively old Mac that I was inspecting recently, I saw a load of entries in the system.log generated by a process named dashboardadvisoryd. The errors follow this pattern:

    dashboardadvisoryd[4326]: fetch: advisory list is not the correct format, could not obtain being marker
    dashboardadvisoryd[4326]: fetch: unable to get sql from net
    dashboardadvisoryd[4326]: fetch-parsers: unable to fetch data from read stream

As is common with Mac errors, a quick search turned up only one result, an unanswered 10-year-old post on the Apple forums.

Not being familiar with dashboardadvisoryd, I poked around a bit to see if I could track down what's throwing the error. The binary itself is part of the Dock, and lives at:

    /System/Library/CoreServices/Dock.app/Contents/Reso...