@SuperDicq @john @jianmin

I'm not a PHP hater but I think it still has a lot of warts and foot-guns left over from old days. I shot myself in the foot via the following construct about 1-2 years ago and I think this flaw still exists in PHP today:

In my MediaWiki installation's LocalSettings.php file, I included the statement require '../.secrets.php'; so I could commit the settings file to version control without leaking any secret tokens like passwords in it. I then put variable assignments pertaining to database passwords and such into that .secrets.php file.

As a PHP expert, I'm sure you already see where this is going. My passwords are suddenly spat out in plain text at the top of all pages to all visitors of the site. Holy shit. Swiftly reverted the change and changed all those passwords, and thankfully one would have first needed a local user account on the server to be able to exploit this (MariaDB only accepting local connections and such), but still...

The reason it happened, of course, was that I forgot to start the file .secrets.php with the <?php magic token. So it was seen as text to include verbatim in the output of PHP. Rookie mistake, I know, but still, it's kind of insane. I'm not sure why they didn't deprecate the include/require family of statements years ago, replacing them with something that will interpret the given file as code, regardless of whether it starts with the <?php token.

Another issue I noticed the other day, but this time just a minor annoying wart:

if ($_SERVER['FOOBAR'] === blah) ... will log a warning if the code is executed locally instead of over CGI such that $_SERVER isn't populated.

In a modern language, I would have expected a function like $_SERVER->get(key, fallback) to exist. In PHP, apparently the idiomatic thing to do is use the null-coalescing operator, like if ( ($_SERVER['FOOBAR'] ?? '') === blah ) ... which is quite counter-intuitive because this means the expression leading to the warning is still being evaluated, but that operator apparently silences it.

These kinds of issues increase the "WTFs per Minute" count while working with PHP.

Another thing that I really hate, but this time I think it's an architectural issue in MediaWiki rather than inherent to PHP, is that any errors in third-party MediaWiki extensions lead to your wiki just returning a completely blank page. No graceful degradation. But I know PHP has exceptions so this is probably MediaWiki's fuck-up.

Sorry, this ended up being a long post. I like to yap a lot.

@kura @hj

Some observations:

When my client (Firefox) asks my server (Pleroma) for the post, the JSON I receive contains things like &quot; in the "description" string:

https://fedi.feministwiki.org/api/v1/statuses/AsRQBdtUVWvsKoMlcW

This seems wrong; the string is just a JSON string, and the client is responsible for rendering it as part of some UI that may or may not involve any HTML.

(Even if it involves HTML, the client should be using APIs to generate a valid HTML Element, for which it doesn't need to use escapes, since no parsing of HTML will be involved.)

In contrast, when I visit the hai.z0ne.social link, I see Firefox sending a POST to:

https://hai.z0ne.social/api/notes/children

With the request body:

Which yields a response including some "comment" and "text" JSON string fields that contain the alt text / title for the video, and those do NOT contain things like &quot;.

This doesn't prove that it's Pleroma's fault: It could be the case that Misskey stores &quot; etc. in the database, and strips those again before responding to its client, but this seems doubtful.

I don't know enough about ActivityPub to be able to ask the hai.z0ne.social server for the post through the actual AP protocol; that would definitively reveal the culprit, I think.