From the release notes change in 0b8b539a00226fb381a5c760bfc377a43fed558f:

If the openssl and mcrypt PHP extensions are both unavailable, secure session storage (soon to be used for login) will raise an exception. This exception may be bypassed by setting $wgSessionInsecureSecrets = true.

The algorithm is aes-256-ctr, FWIW.

This sounds like a breaking change?

Wikis when updating to a new version of MediaWiki will find their login form throws a fatal when their users login? It took me a couple of days to notice.

Surely we could do something better than a PHP fatal here? ie. a message with instructions on what the admin needs to do?

Change 291835 had a related patch set uploaded (by Gergő Tisza):
Fix encryption code in Session

https://gerrit.wikimedia.org/r/291835

In T136587#2339884, @Jdlrobson wrote:

This sounds like a breaking change?

Added to MediaWiki 1.27#Breaking_changes (and it's already in the release notes). Do you know of any other place where it should be mentioned?

Wikis when updating to a new version of MediaWiki will find their login form throws a fatal when their users login? It took me a couple of days to notice.
Surely we could do something better than a PHP fatal here? ie. a message with instructions on what the admin needs to do?

Sure, the fatal is a bug in the code.

Change 291835 merged by jenkins-bot:
Fix encryption code in Session

https://gerrit.wikimedia.org/r/291835

After applying the path and trying to create a new user, I get

PHP Warning:  hash_pbkdf2(): Iterations must be a positive integer: 0 in /srv/www/vhosts/wiki127/includes/session/Session.php on line 401

using OpenSSL 0.9.8j-fips

It sounds like you have set $wgSessionPbkdf2Iterations to 0.

In T136587#2344295, @Tgr wrote:

It sounds like you have set $wgSessionPbkdf2Iterations to 0.

No.
But I added

$wgSessionPbkdf2Iterations = 10001;

and now it's working.
Thx!

I'm going to respond here to a comment that @Tgr made in T137926

In T137926#2385551, @Tgr wrote:

FWIW, besides the five extensions mentioned in the task description, we sort of require openssl or mcrypt as well for core (since 0b8b539).

$wgSessionInsecureSecrets = true is a puzzling compromise at first glance, since I gather that's how "required" became "sort of required". Is this config option something y'all are planning to quickly deprecate?

The plan was to pull in a crypto library which has pure-PHP fallback (phpseclib being the obvious choice there) and remove the option at the time. Doing that is very simple, doing the security review for it is probably a massive amount of work. Not sure where that puts us wrt quickly.

Any news on this? Tried again with a fresh installation of 1.27 and still can't login. No matter, if I use `$wgSessionInsecureSecrets = true`` and/or `$wgSessionPbkdf2Iterations = 10001;``

Change 296534 had a related patch set uploaded (by Gergő Tisza):
Fix encryption code in Session

https://gerrit.wikimedia.org/r/296534

Change 296534 merged by jenkins-bot:
Fix encryption code in Session

https://gerrit.wikimedia.org/r/296534

Backported fix to 1.27. @demon is this worth a point release? Affects people who

• have php-openssl, but it does not support aes-256-ctr mode
• do not have php-openssl, do have php-mcrypt, but it does not support rijndael-128 mode

No clue how common those conditions are.

I'm adding Security to make sure this is on the Security team's radar.

No clue how common those conditions are.

We are using SLES11 SP4 and MW1.27.0. No idea if this is a common combination.

In T136587#2414114, @Tgr wrote:

Backported fix to 1.27. @demon is this worth a point release? Affects people who

• have php-openssl, but it does not support aes-256-ctr mode
• do not have php-openssl, do have php-mcrypt, but it does not support rijndael-128 mode

No clue how common those conditions are.

Probably should tbh.

have php-openssl, but it does not support aes-256-ctr mode

Because of the way we're doing encrypt-then-mac with a random IV for each use, we could change aes-256-ctr to aes-256-cbc (that should be slightly more supported). I think the php api into openssl automatically sets up pkcs7 padding option with cbc. So that would basically make our token the same as python's fernet tokens. So I would feel comfortable with that.

Change 296925 had a related patch set uploaded (by Anomie):
Session: Improvements to encryption functionality

https://gerrit.wikimedia.org/r/296925

Change 296925 merged by jenkins-bot:
Session: Improvements to encryption functionality

https://gerrit.wikimedia.org/r/296925

In T136587#2421582, @gerritbot wrote:

Change 296925 had a related patch set uploaded (by Anomie):
Session: Improvements to encryption functionality

https://gerrit.wikimedia.org/r/296925

This needs to be backported to 1.27.

Change 302297 had a related patch set uploaded (by Gergő Tisza):
Session: Improvements to encryption functionality

https://gerrit.wikimedia.org/r/302297

Change 302297 merged by jenkins-bot:
Session: Improvements to encryption functionality

https://gerrit.wikimedia.org/r/302297

Woah, that was fast. Thanks @Tgr.