Mastobot: For your Fediverse PHP posting needs – Larry Garfield

Mastobot: For your Fediverse PHP posting needs

Like much of the world I’ve been working to migrate off of Twitter to Mastodon and the rest of the Fediverse. Along with a new network is the need for new automation tools, and I’ve taken this opportunity to scratch my own itch and finally build an auto-posting bot for my own needs. And it is, of course, available as Free Software.

Announcing Mastobot! Your PHP-based Mastodon auto-poster.

Continue reading this post on PeakD.

23 January 2023 – 10:13pm

Knex (with MySQL) had a very scary SQL injection – Evert Pot

Knex recently released a new version this week (2.4.0). Before this version,
Knex had a pretty scary SQL injection. Knex currently has 1.3 million weekly
downloads and is quite popular.

The security bug is probably one of the worst SQL injections I’ve seen in recent
memory, especially considering the scope and popularity.

If you want to get straight to the details:

My understanding of this bug

If I understand the vulnerability correctly, I feel this can impact a very
large number of sites using Knex. Even more so if you use Express.

I’ll try to explain through a simple example. Say, you have MySQL table structured
like this:

CREATE TABLE `users` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`)

And you have a query that does a SELECT using Knex:

const lookupId = 2; const result = await knex('users') .select(['id', 'name']) .where({ id: lookupId });

You’d expect the query to end up roughly like this

SELECT `id`, `name` FROM `users` WHERE `id` = 2

The issue is when the user controls the value of lookupId. If somehow they
can turn this into an object like this:

const lookupId = { name: 'foo'

You might expect an error from Knex, but instead it generates the following query:

SELECT `id`, `name` FROM `users` WHERE `id` = `name` = 'foo'

This query is not invalid. I don’t fully understand fully understand MySQL’s behavior,
but it causes the WHERE clause to be ignored and the result is equivalent to:


Truncated by Planet PHP, read more at the original (another 8765 bytes)

Xdebug Update: December 2022 – Derick Rethans

Xdebug Update: December 2022

In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 45% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In the last month, I spend 25 hours on Xdebug, with 21 hours funded. Sponsorships are continuing to decline, which makes it harder for me to dedicate time for maintenance and development.

Xdebug Videos

I have published two new videos:

I have continued writing scripts for videos about Xdebug 3.2’s features, and am also intending to make a video about “Running Xdebug in Production”, as well as one on using the updated “xdebug.client_discovery_header” feature (from Xdebug 3.1).

You can find all previous videos on my YouTube channel.

I wish JSON5 was more popular – Evert Pot

As developers we write a lot of code, but we also deal with a lot of
configuration files.

The three major formats I tend to use day to day are:

  • JSON
  • YAML
  • .env

And, they all kinda suck. JSON feels like it should
never have become a format that people hand-write. So many quotes, and
and configuration files need comments to tell users why certain decisions
were made. .env has a specific purpose (and it’s ok at that), but it’s not a
great universal format, and YAML has always been difficult to read and write to me.
I can somehow never retain the syntax and end up copy-pasting things from examples.

Why YAML is difficult for me

A small example from Github workflows/actions:

steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 14 registry-url: - run: npm ci - run: npm publish

I couldn’t tell you why uses has a dash in front, and node-version does
not. If there’s a difference in how a YAML reader outputs them, I’m not sure
how I would be able to retain this while writing YAML.

I also use/love home assistant, which lets you write some pretty cool
automations using YAML. I wanted to play with
this but it’s been a barrier I’ve not been able to overcome. I don’t know
if it’s me. I’m been working as a programmer for 22 years. I’m decent at it,
but when when I chat with some of my peers (hi mhum!) they did not share my

YAML can also have very surprising behavior, with casting types:

From the linked article, this:

- country1: ca
- country2: no


- country1: ca
- country2: false

I’m sure there’s YAML linters out there that help avoid the pitfalls, but in
my mind configuration files should be simple.

There’s some configuration formats I like, such as TOML and JSON5.
They strike the right balance to me with being easy to read and
write, unambigious, supporting comments, strictness and not being incredibly
hard to write a parser for.

TOML is like ini files on steroids, and JSON5 is JSON but with fewer quotes,
comments and multi-line strings.

I could write my NPM configuration file as package.json5 and automatically
convert it to package.json but that feels too surprising. My projects are
already kind of eclectic, so I want the ‘plumbing’ to be unsurprising. Plus
there’s the whole chicken and egg thing with needing a JSON5 parser before we
have dependencies.

I’d love the NPM project to adopt JSON5. It seems like a great fit. JSON and
YAML can’t be the final word for human-maintained data formats. It’s so
obviously sub-optimal.

If NPM adopted JSON5, I would annotate so much in my package.json. I’d
document why a dependency is needed, why we are stuck using a previous major
version of a dependency and what the purpose is of each script.

I wouldn’t know what format would be ideal for Github Actions. Maybe the
answer is ‘nothing’ and they need a good DSL.

And while we’re at it, stop polluting my projects root directory! Can’t we
all agree on a .meta directory for finding configuration files?

Migrating from self-hosted in Kubernetes Databases to managed hosted at Digital Ocean or the story of how I started working on Opportunistic TLS in ReactPHP – Cees-Jan Kiewiet

One of the things I’ve been planning for months, is to move my self-hosted Redis, PostgreSQL, and MySQL servers from hosting it inside my Kubernetes cluster to managed hosted at DigitalOcean.
At $15 each, I would have to save at least $45 on Kubernetes cluster resources (nodes and volumes) by moving them. In the end, I succeeded at that and probably will end up saving even more as I’m
moving some Prometheus exporters for certain things into my home Kubernetes cluster. (Less expensive per month to run and not super important to have a high uptime/availability, to be honest.) Plus I’ve
been cutting down on services. On the plus side it comes with shiny graphs to look inside how the managed databases are doing

DigitalOcean Hosted PostgreSQL Throughput graph