Abusing my platform here for a sec to spread the word: tumblr now offers https for your blog’s subdomain. You have to manually turn it on in settings on a blog-by-blog basis (and it doesn’t work for custom domains because Thrilling Technical Reasons). Hopefully this is a stepping stone to taking tumblr 100% https but this is important and you should turn it on to help make everyone’s day a little more private. If your blog theme directly includes things by url over http, check whether those urls are also available over https or can be rehosted somewhere with https to make your theme https-safe. Thanks to the people at tumblr, especially Aloria because I kinda assume everyone at tumblr is Aloria.

PHP 7 Look, just… let’s not talk about a 20-year-old language listing “abstract syntax tree” in a changelog, just upgrade to it, okay: http://php.net/archive/2015.php#id2015-12-03-1 Or stay on PHP 4 like you’ve been doing for a decade, and continue to make my job difficult. :)

Crypto Toys PSA “Everyone” knows what I’m about to say, but “everyone” has to learn it sometime. This only indirectly relates to PHP in that the original implementation of what I’m about to talk about was in PHP, which is unsurprising to me, but that’s not the point. The code is a few years old and the author, having been contacted, pulled it off Github – but various forks and manual copy/pastes remain, on Github and presumably elsewhere. I will not be naming the author. It’s well-known advice not to “invent your own crypto algorithm,” and most people are easily convinced of the logic of it: no matter how good a programmer you are, you are probably not the single cleverest puzzle-solver on earth and puzzle-solving-lovers hold conferences specifically to figure out how to break crypto algorithms. There are plenty of algorithms that have survived years and years of this to pick from without you introducing a million ways to mess up. Less known and less agreed-upon is “don’t implement the algorithm yourself either; grab a well-tested implementation.” Obviously someone has to implement them, for a wide variety of languages and platforms; the total number of crypto implementors the world needs is substantially higher than the number of algorithm designers the world needs. In principle, any crypto algorithm should have a specification that’s clear and unambiguous enough that any experienced programmer could implement it perfectly. In practice there are a ton of concerns that don’t boil down neatly to spec form like “be immune to side channel attacks” and a lot of professionally implemented crypto has been broken by such things. Even so, implementing crypto can be a fun, educational experience, so there are thousands of toy implementations of SHA-1 or what have you loitering on hard drives around the world. There is a serious public safety danger in publishing these toy implementations, especially if they’re not blaringly bracketed with “this is not safe for real use” warnings, because newbie, lazy, or self-taught programmers ignorant of the danger absolutely will find them and copy/paste them into production settings somewhere. Some of these toy implementations are reasonably safe. Some people don’t realize their toy implementation is a toy and treat it as production-ready because it works. Sometimes code with catastrophic errors gets left lying around where people searching for “RSA PHP” or somesuch will find it. The implementation in question has a apocalyptic error that boils down to a misunderstanding of the RSA algorithm’s spec (or a decision to simplify the hard parts). If you check most explanations, you will find a line like “Pick two large primes, p and q.” This is shorthand for “pick two extraordinarily large primes from the set of all possible prime numbers in the world, such that trying to guess which two you picked would be an exercise in the mathematically absurd.” I’m not a cryptographer, mind. But that’s the gist. The following screenshot may illuminate the error. It’s a fixed array of a few hundred very small (in computational terms) primes, from which p and q are chosen. This makes cracking the resulting encrypted messages something an academic would sneeringly call “trivial.” This probably happened after wondering how on earth one “picks primes” exactly, a reasonable question with really quite a detailed answer. The result is a toy implementation which was probably fun to make but is absolutely, completely, utterly, indescribably unsafe to actually use to protect real communications. But it’s been forked or copied on Github dozens of times. The table even made it into implementations of other algorithms entirely! Is this one even the ultimate source of the table? I don’t actually know. But that would only illustrate the point further. Incidentally, the code also exhibits the evergreen crypto error of seeding random with the current time, which no matter how fine a timestamp resolution you use is still Pretty Crackable because anyone can come up with a rough estimate of when something was encrypted if indeed they don’t know already know exactly when. This has happened a trillion times because of a long-standing design flaw in PHP – the built-in rand methods are simply not cryptographically secure. To get that you have had to rely on libraries which couldn’t be counted on to be present on every platform or rando cheap host. PHP 7 has new stuff to remediate this. Yay! The long tail of legacy will hold us down for ten years yet! Boo! If you casually implement some crypto for school or fun, please don’t put it on github where it will proliferate. Especially if it’s in PHP. Just. Because. You know. If you’ll excuse me, I need to find and set fire to that SHA-1 code I wrote eight years ago as a sophomore.

and that’s the difference. Fiora Aeterna said: php == easy but php === hard (this blog is not dead. Like the phoenix rising from the garbage collector, it’s just trying to find enough time to hate PHP between sixteen other projects.)

Better late and spearheaded by another corporation than never Of interest to the readers of PHP Manual Masterpieces may be the advent of the PHP specification. Twenty years after PHP was started, that is, and apparently mostly being pushed by HHVM i.e. Facebook. Meh, my toy language doesn’t have a spec so who am I to criticize? It’s extremely long and I haven’t read most of it yet but I assume that formalizing some long-standing insanity as bug-for-bug compatible is an inescapable requirement. It doesn’t cover the standard library, however, which is what really makes PHP what it is (both good and bad). But mostly I was just baffled by comment #4 on that announcement page. What on earth does PHP’s speed have to do with anything when talking about specifications? Y'all PHP fans can have a discussion about the language without bringing up that it’s fast and supports C extensions (or rather it’s fast when what you’re doing is implemented mostly in C extensions). Try it some time!

This blog writes itself. DateTimeImmutable::modify() Alters the timestamp. Like DateTime::modify() but works with DateTimeImmutable . Duh. I don’t see what’s so hard about this, @pda. Of course, it doesn’t actually do what the name says and modify an unmodifiable object at all. So, at least there’s that; PHP didn’t actually go through with its threat. SUPER EDIT FUN TIME! The following article by someone who worked on this code was pointed out to me on Twitter by @GDMac: http://derickrethans.nl/immutable-datetime.html

Nothing Is Deprecated, Everything Is Permitted Blogging something real quick while I maybe look to see what kind of fun factor I can get out of the Mt. Gox leak: It is absolutely 100% true that PHP, the platform, has finally deprecated a bunch of Dumb Stuff, and in some cases has even gotten past the deprecation stage to remove the Dumbest Stuff completely. This is good! This is great. But that doesn’t mean PHP, the community, is suddenly absolved of the problems those misfeatures brought in the first place. For one thing, most PHP deployments are not continuously upgrading to the newest version of PHP or even the newest stable. The last time I wanted to test something, I had to pull PHP and compile it from scratch because the features in question weren’t in Debian yet. However, some people were already saying that the assorted changes in PHP 5.4 meant I couldn’t pick on those things anymore, before 5.4 was available through standard package distribution! More critically, though, is that the amount of PHP code in production which is old will always exceed that which is new. The normal lifecycle of a piece of code is to write it once, make notable adjustments once or twice, and put it on minimum maintenance forever until the website goes away. The majority of commercial PHP code that I have seen with my own eyes clearly dates to the PHP 4 era or was written by someone who stopped learning in the PHP 4 era, which was the perfect storm of popularity and screwed-up-ness. This code did not magically get better when it was acknowledged that certain language features were bad news. It stayed more or less exactly the same. It’s still running. Old code does not magically improve. New code is often written with reference to old code. Heck, new code is often literally just copy-pasted from a forum comment written in 2003. PHP’s misfeatures will persist many years past the official attempt to fix them. And that’s terrible :(

I thought @eevee was putting me on. And now you think I’m putting you on. But I’m not. But it’s not like anyone would ever notice - no-one is blocking javascript on php.net after the malicious javascript incident! You know, the one we’ve been waiting for the full postmortem on since October? In all seriousness, if they cannot determine the root cause of the breach, they should say so for the record: it happens. It means whatever went wrong could probably go wrong again, but, it happens. From my point of view, their incident response kind of fell apart for a while due to confusion; I hope they have regrouped and learned from the experience so that it goes smoother next time. I’m not being snarky. Incident response is hard. I’d laugh and cry myself to death, though, if this was them getting hacked again but apparently it’s just someone with commit access being cutesy.

Regarding "On the interest of being fair", h t t p : / / a x o n f l u x . c o m / 5 - q u o t e s - b y - t h e - c r e a t o r - o f - p h p - r a s m u s - l e r d o r f -- why wouldn't tumblr let me include links?! Anonymous Scorched earth anti-spam policy. I guess we know where Twitter learned it from. For readers’ convenience: link that Tumblr’s markdown parser better figure out godsdam I personally am of the opinion that not everybody needs to like programming and take an artist’s pride in their results - but I do kinda maybe want the people who make the tools intended for reuse by thousands to have that quality. I really like how Tumblr creates answers to asks in WYSIWYG then when I edit them they suddenly become markdown except with HTML tags everywhere. Isn’t this site written in PHP…? ;)