I'm struggling to see how "deprecation procedures" can necessarily be followed, as this isn't deprecation for removal, like that policy is mostly aimed towards.

This is related to T232354: New vagrant instance not setting password for `admin` user to `vagrant`

Master has a fix for that, so it could mostly just be asking them to release the fix - https://github.com/romaricdrigon/MetaYaml/commit/1481b99679b29cbb50c88f3e10e4951ac64b8ad3

In T235389#5571256, @dbarratt wrote:

In T235389#5571221, @Reedy wrote:

And FWIW, CheckUser stores IPs as the string and as a hexadecimal representation, which it uses for IP comparison and maths...

Yes, so does ipblocks, but wikibase does not have a way to store ranges in hexadecimal format, so rather than building one, it would be simpler to store them in decimal format.

And FWIW, CheckUser stores IPs as the string and as a hexadecimal representation, which it uses for IP comparison and maths...

Given the IP address 198.35.26.5 it is impossible to reason that the IP address belongs to Wikimedia Foundation.

Current implementation:

Reverting out of 1.35.0-wmf.1 (for now), due to ~240K errors in 90 minutes on enwiki

I think https://github.com/wikimedia/mediawiki/commit/a8525d7201dada88f3117142fe1919d0b9b80d4e is to blame

Sorted now. Some possible bumps to be done, but that’s a different problem

In T234987#5564319, @sbassett wrote:

In T234987#5557911, @Reedy wrote:

I filed this as a security bug. I honestly don't know if it needs to be. As it's basically ongoing hardening

It's all in CommonSettings.php, right? I'd guess this can probably be public.

HHVM is definitely gone now :)

In T224949#5566036, @daniel wrote:

In T224949#5565266, @Reedy wrote:

I got bored of just kicking the failing test can down the road after 5 supporting backports to REL1_32 and REL1_33 to help this change

So when someone runs into that problem while installing 1.32 or 1.33, we just tell them to install 1.34 instead? Seems acceptable, since this seems to be rare enough.

Except, it still clung onto the old versions...

Version bump reverted, as it's tracking ruflin/elastica versions

I think the only thing that is outstanding, but not tagged to this task is the commit to bump CirrusSearch to use the Elastica version with the versions of the libraries that don't require >= 5.6.99 - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CirrusSearch/+/542270/ but Cindy doesn't like it, for reasons I don't quite understand

I got bored of just kicking the failing test can down the road after 5 supporting backports to REL1_32 and REL1_33 to help this change

In T235230#5564890, @RhinosF1 wrote:

@Reedy not on the current one but in T226059 you mentioned adding links which can't be done with this 'issue'

This isn't a bug, it's a feature request

T197535: extension.json should be able to express dependency on PHP version / PHP extension version

In T235160#5564075, @MGChecker wrote:

I implemented the php requirements for extension.json, and @Legoktm and me thought it should be used the same way @Daimona proposes: A php requirement should only be specified, if an extension requires a php version higher than the minimum supported php version for the minimum supported MW core version. I think for composer.json, we should use the same approach.

Debian stable is on 7.3 so that's all good. Old stable is 7.0 so we don't care

It's been at MediaWiki for 14 years - https://www.mediawiki.org/w/index.php?title=MediaWiki:Mainpage&action=history

In T233963#5563743, @BPirkle wrote:

@Reedy, the OATHAuth and WebAuthn patches look like they're generally on the right track to me and unless that approach proves to be unnecessarily painful, I'd recommend continuing that direction.
This change (the one I'm commenting on, which modified RESTBagOStuff) gave us the flexibility to pick either PHP or JSON serialization for sessions stored in Kask. But that leaves the open question "which are we actually going to use", which was raised in T233537: Document and communicate potentially breaking session storage serialization change.
Which leaves the people working on OATHAuth and WebAuthn in a rough spot, because you need to know that things you store in sessions will work.
The safest approach is to do exactly what those patches are already doing - ensure that you aren't storing proper PHP objects. The alternative is to go ahead and have the discussion about which format we're actually going to use. But I think we're all on various short timelines and resolving that quickly might be challenging.
Is that helpful at all?
I made a comment on one of the patches regarding nesting, and some test code that I played around with locally.

See also T215798: Insecure password warning seems to break local Selenium tests and T232354: New vagrant instance not setting password for `admin` user to `vagrant`

I (@Daimona) think that extensions should *not* have an explicit PHP version requirement, unless it's (meant to be) different from the one in core.

Is this a bug about Phabricator? I think you might be reporting it in the wrong place...

In T121947#5558144, @Jdlrobson wrote:

In T121947#5558095, @Krinkle wrote:

This library is using extreme measures with regards to security and performance. It only barely got through our 2015 audit, with a lot of work on our end to integrate and contain it. I think if this were proposed as a new library today, I don't think we'd be as lenient.

Is using another more minimal mustache template library an optional? If so I'd suggest doing that and marking the lightncandy library as deprecated.
Supporting custom helpers such as ifCond was certainly out of scope when we put templating in core. My understanding was Mustache was chosen for the very fact it was minimal.

Current failure on core from flow...

Vendor failing due to what is basically a cyclic dependancy on it and core

In T121947#5558066, @Jdlrobson wrote:

I guess first step would be to restore the upgrade and take a look at the test failures. To be honest I'm surprised to see direct usage of LightNCandy in this way. I thought TemplateParser was the only public class we support.
I know a little about Flow so hopefully I can do some of the upgrading there if needed but I'd like to understand if there's any Minerva problems.

An amusing one to me was finding this in BlueSpice Foundation to just add helpers...

In T121947#5558018, @Jdlrobson wrote:

Do the breaking changes impact Flow only? This seems pretty serious and I'm surprised this has been sitting here since 2015. Is there anything I can do to help?

I do feel if we're going to be suggesting this is the way forward to do things (for whatever reasons)... We should get some love to lightncandy in MW Core and extensions that use it, rather than just sitting on an old unsupported version which is 0.23