Fatal error in WP_Session_Tokens::hash_token()

[SergeyBiryukov]

Seeing some reports on support forums with the update to 4.0:

Fatal error: Call to undefined function hash() in wp-includes/session.php on line 64

Apparently Hash extension can be disabled.

[nacin]

Oh dammit, we knew this and have been accounting for hash_hmac() for years.

Luckily last time we sampled it, it was like 0.12% or something crazy small, but that's still tens of thousands of sites.

[nacin]

29518.diff​ falls back to sha1() if ext/hash is disabled.

For sites that have ext/hash currently:

• No change. Sessions and cookies generated in 4.0 will work after update to 4.0.1.

For sites that don't have ext/hash:

• No change from 3.9, and sessions simply use sha1.

For sites that loose ext/hash:

• Their sessions and cookies will become invalidated. Also, WTF?

For sites that already updated to 4.0 and are issuing fatal errors:

• Cron won't run any authentication functions, which means an automatic update can rescue these sites. This is pretty meaningless as it doesn't affect many people, but still — FTW. It also means we don't need to rush a 4.0.1 for this, which I loathe to do anyway.

For now, the support forums recommendation should be to:

• Change sha256 to sha1 wherever it appears in pluggable.php (twice)
• Change return hash( 'sha256', $token ); in session.php to return sha1( $token );
• Update to 4.0.1 when it comes out (if it isn't automatic for them) to get the "proper" changs/

(function_exists( 'hash' ) ? 'sha256' : 'sha1' looks really weird and will need a code comment.)

[nacin]

Thanks mdawaffe for talking this through with me. Together we came up with way more insane solutions that will never see the light of day.

[voldemortensen]

Added documentation.

[nacin]

Ah, thanks. I ended up having somewhat clearer docs locally already. see 29518.3.diff​.

[DrewAPicture]

The docs in 29518.3.diff​ should work. Might be worth adding a blank line above the commented block just so it doesn't get lost in a block of code.

[jorhett]

I would highly recommend that you push out an immediate fix to sample for whether hash works by running a quick test before doing the upgrade that you are very demandy about in the wordpress dashboard. Right now that's a button to kill your site, and for hosted blogs where the provider isn't quick to update packages they will be dead in the water.

easier than a complete fix -- just add a test for hash, and report back to the user instead of upgrading.

[nacin]

Replying to jorhett:

I would highly recommend that you push out an immediate fix to sample for whether hash works by running a quick test before doing the upgrade that you are very demandy about in the wordpress dashboard. Right now that's a button to kill your site, and for hosted blogs where the provider isn't quick to update packages they will be dead in the water.

easier than a complete fix -- just add a test for hash, and report back to the user instead of upgrading.

We'll definitely ship this in 4.0.1, expecting in the next 5 days I'd say. This affects very, very few sites. And honestly, a site breaking over this means they'll be forced to contact their host to get this resolved, which isn't the end of the world, because they're essentially dealing with a borked PHP install — and because their content is ultimately OK, and even the frontend of their site is ultimately OK, as would an auto update.

Going to go ahead and get this committed.

[SergeyBiryukov]

[29751] missed the ticket.

[nacin]

So did [29761].