MWCryptHKDF was added ten years ago (in af66c04d39), and as far as
I can tell, it was never used anywhere. It seems unlikely that CryptHKDF
will be used in the future, at least in its current form, for several
reasons:
* PHP 7.1.2+ has hash_hkdf(), so HKDF() would not be needed.
* At the time MWCryptHKDF was created, access to a CSPRNG was dependent
on server configuration: operating system, enabled PHP extensions,
open_basedir, etc. The "clock drift" RNG used as a last resort was not
considered to be secure or fast enough for generating large amounts of
output.[1] random_bytes(), added in PHP 7, changed the situation.
* Depleting the input pool of Linux's RNG is no longer a concern; there
is no more blocking output pool for /dev/random.[2][3] In 2022, this
change and others, including some that improved performance,[4] were
backported to stable kernels as old as 4.9.[5]
* $wgAuthenticationTokenVersion obviated the primary use case of
quickly resetting the user_token field for all users, assuming all
the existing tokens are unique.
* CryptHKDF seems to perform much slower than random_bytes(), at least
on Linux, making it pointless to use given that the other reasons for
its existence no longer apply.
[1]: https://bots.wmflabs.org/logs/%23mediawiki-core/20161004.txt
[2]: https://lwn.net/Articles/808575/
[3]: https://lore.kernel.org/all/cover.1577088521.git.luto@kernel.org/
[4]: https://www.zx2c4.com/projects/linux-rng-5.17-5.18/
[5]: https://lore.kernel.org/all/Yo3pmh9hiUFtQz77@zx2c4.com/T/
Change-Id: I29136fad826341d21728671aa30285d5551f1162
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I73fb416573f5af600e529d224b5beb5d2e3d27d3
Why:
To facilitate the evaluation of conditions not directly
"known" by the lookup, eg: owned by extensions
What:
- Add ConditionalDefaultOptionsAddCondition hook which
runs before instantiating ConditionalDefaultsLookup allowing
to add conditions for evaluation in the $extraConditions
array.
- Evaluate the configured conditional default against the
extra added conditions after evaluation of "known"
conditions.
Bug: T376918
Change-Id: Ife6f96397eafd61fdb40528aac315ddde1ef2774
And use that as much as possible. This makes bootstraping services much
faster since Language object is extremely heavy (specially to
initialize) and that's why in LanguageFactory it's behind a cache (see
LanguageFactory::getRawLanguage)
At the same time, most uses of Language object only need the language
code (after normalization and mapping and validation) and this allows
such change to happen fast and way more decoupled from Language object
that has more than 100 methods.
Bug: T376565
Change-Id: I1c3d94454896842939dfaad8cbf742e5a3ae5438
This adds support for serializing/deserializing objects which
implement the JsonCodecable interface from the wikimedia/json-codec
library used by Parsoid. JsonCodecable allows customizing the encoding
of objects of a given class using a class-specific codec object, and
JsonCodecable is an interface which is defined and can be used outside
mediawiki core.
In addition json-codec supports deserialization in the presence of
aliased class names, fixing T353883.
Backward and forward compatibility established via the mechanism
described in
https://www.mediawiki.org/wiki/Manual:Parser_cache/Serialization_compatibility
Test data generated by this patch was added in
I109640b510cef9b3b870a8c188f3b4f086d75d06 to ensure forward
compatibility with the output after this patch is merged.
Benchmarks:
PHP 7.4.33 PHP 8.2.19 PHP 8.3.6
BEFORE AFTER BEFORE AFTER BEFORE AFTER
Serialize: 926.7/s 1424.8/s 978.5/s 1542.4/s 1023.5/s 1488.6/s
Serialize (assoc): 930.2/s 1378.6/s 974.6/s 1541.9/s 1022.4/s 1463.4/s
Deserialize: 1942.7/s 1961.3/s 2118.8/s 2175.9/s 2129.8/s 2063.5/s
Deserialize (assoc): 1952.0/s 1905.7/s 2107.5/s 2192.1/s 2153.3/s 2011.1/s
These numbers definitely do not have as many significant digits as
written here. But they should be sufficient to demonstrate that
performance is not impaired by this patch and in fact serialization
speed improves slightly.
Bug: T273540
Bug: T327439
Bug: T346829
Bug: T353883
Depends-On: If1d70ba18712839615c1f4fea236843ffebc8645
Change-Id: Ia1017dcef462f3ac1ff5112106f7df81f5cc384f
In T340552, the official PHP OpenTelemetry client was effectively
rejected for inclusion in MediaWiki due to its size. Implement a minimal
tracing library instead that eschews conformance with the OTEL client
specification in favor of simplicity, while remaining capable of
emitting trace data in OTLP format and thus retaining compatibility with
any ingestion endpoint capable of handling OTLP.
In its current state, the library supports a basic feature set that
should be sufficient for basic tracing integration:
* Span creation, inclusive span activation and automatic parent span
assignment,
* Span attributes and span kinds,
* Basic resource (process/request)-level metadata generation,
* Data export over OTLP.
Additional functionality, such as trace propagation, can then be
incrementally added to the library.
Bug: T340552
Change-Id: Ibc3910058cd7ed064cad293a3cdc091344e66b86
Why:
- Calling getMessage()/getWikiText() with a good Status is a logic error
that converts the Status being operated on into a fatal one.
- However, this error is never logged anywhere, which can make it
difficult to diagnose such cases, as seen in
I17166e988bf389a5b03d4a74f539f7bec7f5997f.
What:
- Add a warning-level log for the case when getMessage() or
getWikiText() is invoked with a good Status.
Bug: T374436
Change-Id: I3efae5c4c336156924f1c9b4186fa9142aaed9ca
In order to replace the /api/rest_v1/page/title/{title} endpoints, we
need to have something in MediaWiki that generates a compatible
responser. The v1/page/{title}/bare and v1/revision/{id}/bare endpoints
are functionally equivalent, so the easiest approach seemed to be to
add a compatibility mode to them. The compatibility mode is triggered
using the x-restbase-compat header, which can be set via the gateway
when routing the request from /api/rest_v1/page/title/.
Bug: T374136
Change-Id: I4af7ff5325660ae30faebb24753b9dc1c3acb2b3
This patch begins migrating the WANObjectCache metrics from graphite
to prometheus. This class can be constructed directly and parameter
options (which might include a stats collector object) passed, so we
need a way to detect the incorrect case and warn accordingly.
Since this is used by extensions, and we want to support only the new
StatsFactory option. We need a way to track and warn places where the
old stats collector is still in use and also put in place a mechanism
so new code doesn't use the old stats collector.
So, constructing a WANObjectCache object with an IBufferingStatsDataFactory
stats collector is deprecated in this patch in favor of the new collector.
Callers are responsible for fixing usage to StatsFactory.
Bug: T359257
Change-Id: If1162f69997b1b914fb9e02dad7d7ae1540d2d01
This allows Parsoid to add tracking categories, even though
the exact name of the categories is resolved by mediawiki
core.
Change-Id: Id4b29c6d09c79649c94d2da2e678af52a967bbe5
Treat the username/email as provided when it's a falsy string ('0').
Refactor away some redundant checks and variables.
Only construct User objects when needed for the hook.
Documentation and code style tweaks.
Change-Id: I499d73dacfb48a95291dcfa0405e52788a0251f4
This code was partially copied into MassMessage and will hopefully
enable more places that accept arbitrary wikitext to check lint errors.
It also hides the internal details of checking with the Linter
extension's configuration in one place until it can be refactored into
something more acceptable (T360809).
Bug: T368690
Change-Id: Iaeb3ccbd61a2a8cb0d8b3dc8b06a3a10bc8fa653
Adds an experimental configuration to allow extensions to define
OutputPipelineStages to include in the DefaultOutputPipeline.
There are a lot of open questions about this api, like ordering of
execution, but adding it @experimental will help surface the
requirements.
Bug: T370541
Needed-By: I6dc92af0611c680b6e55605a7c9ff8a3fc1dfa26
Change-Id: I64baea40a1687c7a06fbcda9efe9f9a159b0ae8d
Since I72c5e6f86b7f081ab5ce7a56f5365d2f75067a78 it is part of the
contract of ContentRenderer::getParserOutput() that the render ID (and
other cache parameters) will be set when it returns.
(ContentHandler::getParserOutput() can set them even earlier if it has
custom content-based overrides.) We had a lot of temporary
backward-compatibility code "later" in the parse process to try to close
the barn door if some code path "forgot" to set them, but these are
unnecessary now.
This patch removes that backward-compatibility code in ParsoidParser;
there is similar remaining code in ParserCache etc. which can be
addressed in follow ups.
(For compatibility we do have to temporarily copy the render ID code
inside ParsoidOutputAccess::parseUncachable, but that class is
deprecated and will be removed.)
The HtmlOutputRendererHelper path which used to call
ParsoidParser::parseFakeRevision() is now replaced with a codepath that
goes through RevisionRenderer. In order to maintain the same behavior
of the ParsoidHandler, we have also added 'useParsoid' handling to the
JsonContentHandler. This support can perhaps be deprecated eventually.
Bug: T350538
Change-Id: I0853624cf785f72fd956c6c2336f979f4402a68f
This removes the last use of ParsoidOutputAccess in core, allowing it
to be deprecated and eventually removed.
Bug: T367074
Bug: T317018
Change-Id: Ica2c880e2e7c2b126aaea66a3e4be460b3f2234f
* Its not very clean to import Wikimedia\Stats in parsoid
* Mediawiki depends on parsoid
* As a workaround we can extract the 2 methods we need in SiteConfig
Bug: T354908
Change-Id: I696131cfba6ccc26ae1f705f216e221a7c3db175
And deprecated aliases for the the no namespaced classes.
ReplicatedBagOStuff that already is deprecated isn't moved.
Bug: T353458
Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
Replace UserCache with UserIdentityLookup
UserIdentityLookup is implemented by ActorStore and
there is already a cache
Change-Id: I8a59e77391da45d2726aab3d5432f08ad0c9a84f
Follow up to c33b31728d
The skin is showing up on Special:Preferences as a selectable
skin. Choosing this would make the site unreadable without applying
?useskin=vector-2022 on the URL.
The last parameter makes it an internal skin and therefore
not shown on preferences page.
Bug: T364696
Change-Id: I3f95b68692fe8ae9d05d2f3187986774ef91ba6d
This allows rendering of the data passed to the skin rendering
layer, to allow developers to debug the information used to render
a skin.
Bug: T364696
Change-Id: I32aaa6a85d24df4f4689269f6a455823bb08196b
* In queryLinks(), use the full result cache even if a limit is
specified. Truncate the result in the caller if necessary.
* Remove the confusing boolean parameter from partitionResult(). Make it
always false and fix up the results afterwards. So the batches are
always the inclusive start and end IDs, false is never returned.
* Inject a logger instead of using wfDebug()
* Use private not protected. Defaulting to protected was just a coding
style quirk I had at the time.
* In queryLinks(), use early return.
* In hooks BacklinkCacheGetConditionsHook and BacklinkCacheGetPrefixHook
adjust the parameter type hint to avoid the need for a Phan override.
Change-Id: Ia53f494633affe48316f0a8b63d03596239ad53c
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ic4d4dd61de5ab896fb6173eb579c81f164a1e4a3
Modifies incrStatsByContent in order to migrate cache_misses, cache_hits to Prometheus backend
Bug: T359465
Change-Id: I78afac7437bc2849b64f43c23477d702b94e907b
