If you aren’t aware – a bug that has persisted for over a decade has come to light with how speculative branching in CPUs (not only Intel, writers) can lead to people able to access others’ volatile data in kernelspace.

What this means, essentially, is that any multiuser system is inherently insecure for any local user access. This is not a good thing.

Patches have been made against the most recent Linux kernels, and should be installed!

If you are running debian stretch, for example, here’s a simple way to get “up to date” with the debian security branch (assuming you are running x86_64):

$sudo $SHELL
#echo 'deb http://security.debian.org/debian-security stretch/updates \
  main contrib non-free' >> /etc/apt/sources.list
#apt-get update
#apt-get install linux-image-4.9.0-5-amd64 iucode-tool
#wget http://ftp.us.debian.org/debian/pool/non-free/i/intel-microcode/\
intel-microcode_3.20171215.1_amd64.deb
#dpkg -i intel-microcode_3.20171215.1_amd64.deb && rm \
  intel-microcode_3.20171215.1_amd64.deb
#reboot

What this does is add debian-security to your apt sources, update the list, install the latest (stock) 4.9.x kernel with the patches against Meltdown, and install a current microcode patch – which only supports a few processors right now, but will likely be updated, so a subsequent update should pull in any future firmware patches.

Of course, this assumes a stock kernel/Debian 9 configuration. If you’re using stretch-backports, there is not yet a 4.14 release available with patches at the time of this post.

One of the annoying things about LetsEncrypt- if you run multiple zones from the same IP, it tends to make them Aliases of the primary zone.

Recently, I’ve worked to break away a couple projects from the primary zone, and it’s not gone all that well, with LE refusing to remove them or renew the other zones with those certificates still being part of the bundle.

So, I’m going to take one on the chin and rebuild all of the certs separately, which causes minimal more load for them, and a big headache for me.

Ok, let’s all take a deep breath.

With “Net Neutrality” being repealed, we’re precisely in the same place we were before 2015.

This actually means relatively little, and it is not very feasible for a provider to remove your ability to visit websites that they do not have an “agreement” with, or to charge you more for “sites not on the list”. It’d certainly gain them no favor, and in fact, with the free market which this is set to further promote, they’d be replaced by another option, possibly at a cut-rate price.

This is not going to stop you from watching cat videos or playing Minecraft. I pinky-promise.

This should be a pretty transparent migration for anyone who happens upon this, but I can’t justify the expense of dedicated machines to serve my pointless websites and services, so I’m migrating everything to cheaper, VPS-based hosting.

We’re now running on a handful of virtualized services, with far lower specifications than the old system, and saving nearly half of the cost. Also, We’re live in Russia, as well as in Germany, to celebrate heritage- and domain names that cost less than $1/yr. For now, all still link to the main site due to a limitation in my blogging software, but I’ll rebuild that functionality.

I’m going to change this design to a simpler, less 2003-styled theme, so things may be broken occasionally while I work on this at my leisure.

It’s been over a decade since I registered my first MX donation to Project HoneyPot- and they’ve noticed that I removed a link because the last few times I tried to register changes, the site was not working.

Well, I’ve figured it out. Their token system for activation is not IPv6 compatible. It’s a pity, but it wasn’t all that difficult to figure out after digging through the code (it is nothing changeable on the client side- and modifying the code will make the client fail it’s internal heuristics, making it trivially more difficult to diagnose).

On the sideline, I’ve been interested in their Http:BL system, which is similar to DNS blocklists, but is designated for HTTP use. This enables a user to decide if they want to block a visitor’s traffic due to it being a harvester/spammer/et al..

I’ll probably dig into existing implementations, and build a TextPattern extension for it (Yep, I’m still using TXP over a decade later, too- after giving up my homegrown CMS that I built with no real design ideology in 2003.)