Skip to content

Sync with upstream#27

Open
github-actions[bot] wants to merge 565 commits into
weirdgloop/REL1_43from
weirdgloop/repo-sync
Open

Sync with upstream#27
github-actions[bot] wants to merge 565 commits into
weirdgloop/REL1_43from
weirdgloop/repo-sync

Conversation

@github-actions

Copy link
Copy Markdown

No description provided.

libraryupgrader and others added 30 commits May 24, 2025 00:15
Change-Id: I83ef54618e9a152c3b2cc30c28b4a5f6ec0dea98
Change-Id: I3cf86073fa9ef7f0c271cfc1dd22f8b4c178b6a5
This was added in I68f8f954ed754c4 because the VariableHolder needed a
backwards compatibility alias.

Now that the old alias has been removed in Ie4817ae1c43c5fb, this line
is no longer needed.

Change-Id: I0c676cbea3432175d27e7a8d0c26a1474f2de1e9
As a follow-up to Idf21edb4965013, rename a variable so that it's
clearer what concept it represents.

Change-Id: I36e432747de585b7df12ff9a73f1e4e62eb3be56
Change-Id: I3b724be3df0bcb7c0b3486b97a55251a5bcda6ba
I found this code surprisingly hard to read. An array being reversed,
used to re-construct parts of a domain from back to front? I believe
the proposed code is easier to read and possibly even faster (one
iteration is removed from the loop).

Change-Id: I028cb2681d2d82b9bdc2e2f4687d948e55fe9c30
Change-Id: Ic6d259160ceb13917720d54c2bd17508f90fbf23
Change-Id: If581b811c424ce9932c372b2a5262c582d47a237
Why:
* For T390873, we need to know when a abuse_filter_log row has
  been purged so we can reliably only process rows which need
  to be processed when purging private data.
* Previously the afl_ip column not being an empty string was used
  for this.
** However, now that we are adding protected variables that need
   purging to afl_var_dump we cannot always reliably say the
   row has been purged if afl_ip is an empty string (because it
   can be empty from creation if $wgAbuseFilterLogIP is false).
** In this case we still need to purge data from afl_var_dump
* Adding an index to allow searching over the first character of
  afl_var_dump will allow determining if the column contains JSON
  and therefore needs purging
** Because rows are only purged after a given amount of time
   since their creation, we also need to add the timestamp to
   the index.
* Other options were considered, but rejected by DBAs:
** Adding a new tinyint column to indicate if a row is purged,
   which would take up more space on an already quite large table.
** Making afl_ip nullable so that a null value indicates that the
   row is purged. However, a null value can cause confusion and
   causes additional problems with any indexes that exist.

What:
* Add the afl_var_dump_timestamp index
** This index partially indexes afl_var_dump by indexing the
   first 4 bytes.
* Apply the schema update when running update.php

Bug: T390873
Change-Id: Ie4cb31a7365f660ae6279f26280681ee63b0d933
Why:
* For T391322, we need to be able to search for abuse_filter_log
  rows by the IP address stored in afl_ip.
** afl_ip stores the IP address in plaintext, which makes it not
   possible to IP address range search.
* Making the IP address be stored in a hexadecimal format will
  allow searching in a manner to how the CheckUser extension does
  searching.
* We could repurpose the existing afl_ip column, but just making it
  store hexadecimal could break existing integration with the table
  that expects that the column be in plaintext.
** Therefore, creating a new column and migrating the data will
   be safer to ensure that all callers are explictly updated in
   a way to expect that it will be in hexadecimal format.
** Furthermore, the column name containing the word "hex" will make
   it easier to see when inspecting the DB what the column would
   contain.

What:
* Add the afl_ip_hex column to the abuse_filter_log table.
** Apply this update when running update.php

Bug: T395613
Change-Id: Ifde2fe79d1e35e2a7389f9be1aedd78b78e7e67b
Filters provide methods to get/set userId and userName. Instead of
handling userId and userName seperately we can use the UserIdentity
istead and pass it as a single object. This simplifies the interface
as there is no need for setters/getters for both and prevents
from situations where only one setter is called.

Additionally this change will be required to:
 - refactor call to deprecated Linker::userLink() as the replacement
 requires a UserIdentity as input instead of id and name pair
 - refactor call to trigger an Echo event, as the RecipientSet
 requires recipients in form of UserIdentity[]

Change-Id: I19e6a3a3d81fb2b130fc2c8d0e51465784987073
When performing an integration test, the EchoNotifier should test
Echo as a blackbox, not test only that some method returns a specific
array.
This change allows us to make getDataForEvent private as previously
it had to be exposed to allow testing. This also will allow us
to pass Recipients from notifyForFilter() without having to call
getFilterObject() twice which may be expensive and at the end redundant.

Change-Id: Ic204a876adbd40a587899d9a32cc415688e8783c
Change-Id: If0062dfac6d9d92d1aa2e1cb41c2af1c894ecd31
Change-Id: I38db4bc926e22a1ab987d01e408ea9441afcd754
Change-Id: I3336c0ae8669b9d87dc7a2ea49c1574f6610cd96
Why:
* Protected variables need to be purged after a 90 days on WMF
  wikis, as the data in them is considered private and so should
  be removed.
** This is so that we can make IPReputation protected variables
   expire for events like account creaton where keeping the data
   indefinitely could lead to this data being availible for users
   who are at a greater risk of doxxing etc.
** While not a requirement from WMF Legal, it allows us to remove
   this data that will no longer be useful for anti-abuse to
   better protect privacy.
* Therefore, we cannot store protected variables in the external
  storage that is append only.
** This means storing these variables in the DB until they are
   to be expired, when at that point the variables are removed
   by a maintenance script keeping the blob store address
   intact.
* First we should update the VariablesBlobStore to support this
  and can consider purging (which requires the
  afl_var_dump_timestamp to exist) at a later stage.

What:
* Update VariablesBlobStore::storeVarDump to not store
  protected variable values in the BlobStore.
** Instead these are added to the returned value by storing the
   protected variables in JSON along with the blob store address.
** If no protected variables are used, then the blob store address
   is returned without being wrapped in JSON
** The user_unnamed_ip variable is not stored in this way, as it's
   value continues to be stored in afl_ip.
* Update VariablesBlobStore::loadVarDump to handle the changes made
  in ::storeVarDump.
** This includes working out if the afl_var_dump value is JSON,
   and if so then extracting blob store address from the JSON and
   adding the protected variable values to the variables from the
   blob store.
* Update the PHPUnit tests for VariablesBlobStore to support this.

Bug: T390873
Change-Id: I49469a3b91d7aaae9358ca7209d8fbdfeeff70ae
This will be conditionally called from either the special page
itself or CommunityConfiguration.

Bug: T393240
Change-Id: I9147e6d9af28456675c71b1b51d8757e8a13c001
…or RevisionStore

Bug: T396056
Change-Id: I4eaaf060c964c6c6bda5f5f857974b24e84a44be
This fixes a 3rd place that would still trigger the deprecation
warning. See line #197.

Bug: T396056
Change-Id: I589930d0d66565b0aa0cf3076be6e836a51ffbe3
Recommended way to pass recipients with Echo Event is to use the
second optional argument $recipientSet. Previously we could pass
the recipients via $info['extra'] array. To simplify the code a bit
and unify the Echo interface with recent NotifyService, all callers
should follow the new interface.

Passing recipients via extra array is still supported as this is how
recipients information is stored internally in Echo, altough it is not
recommended. Passing set of UserIdentities gives a better control and
type safety.

Change-Id: Ie722558c8cd068210992bded9cb13cde768c0c86
Why:
* The IPReputation extension wants to add IPReputation information
  for the current IP when a user creates an account while not
  logged in to another account.
** This is currently not possible with the existing hooks, as the
   ::addUserVars is not called when creating an account while not
   logged in as a registered user.
** Therefore a new hook is needed to add the variables from
   extensions in all cases when an account creation is occuring.
* This commit adds the hook which allows the handler to add
  variables when in the context of an account creation action.
** This hook should provide the creator, created user, whether
   it's an autocreation, the variable holder, and any set
   RecentChanges entry to support the IPReputation extension
   use-case.

What:
* Add the AbuseFilterGenerateAccountCreationVars hook
* Run the new hook in RCVariableGenerator::addCreateAccountVars
  and RunVariableGenerator::getAccountCreationVars.
* Update the PHPUnit tests to ensure that the hook is called when
  it's supposed to and also that the hook parameters are as expected.

Bug: T396079
Change-Id: I8b2ced75f238394bb763bfa9974a5cfded2ac46d
Change-Id: I036b8b04fd7cf09b9b2c2be11d0c486281a285ee
translatewiki and others added 30 commits March 5, 2026 06:00
Change-Id: Ie028d2bf82099952c8731e7a114f119296fe53de
Change-Id: I492813d161f7fce24f429b9d60fad25929ae91f0
* GHSA-25h7-pfq9-p65f

Change-Id: I3cc09938be0f46c46cc81ce07d82ed9ac66d31d5
Change-Id: I0e0c6b94734e1be09bfbfee1783af74bb53d07d4
* GHSA-rf6f-7fwh-wjgh

Change-Id: Icfed83bb76ce475f1c453f8574e5a35c410dce7a
* picomatch: 2.3.1, 4.0.3 → 2.3.2, 4.0.4
  * GHSA-3v7f-55p6-f55p
  * GHSA-c2c7-rcm5-vvqj
* yaml: 2.4.3 → 2.8.3
  * GHSA-48c2-rrv3-qjmp

Change-Id: Ifa4210bf14f08943250121ee9299271f3775dcc1
Change-Id: I3d20e25571aef86faea744d34f258a3a5bb569d7
* GHSA-f886-m6hf-6m8v

Change-Id: Iecb439d8e6c10d0a4bbf1cca2c577f067c21ef16
…nBitfield

CVE-2026-34086

Why:
* AbuseFilter uses `RevisionRecord::userCanBitfield`,
  `LogEventsList::userCanBitfield`, and `ChangesList::userCan` to
  determine whether the context user is allowed to view RC rows and
  revisions with deleted aspects.
* `RevisionRecord::userCanBitfield`:
  * The `$field` parameter doesn't safely accept composite bitfields,
    as implicitly suggested by the doc comment.
  * When composite `$field` masks are passed, the method may only check
    `deletedtext` and skip `deletedhistory` even when necessary,
	depending on the bit combination.
  * As a result, abuse log entries and RC rows associated with user-
    or comment-deleted revisions could be exposed to users lacking
    the `deletedhistory` permission.
* `LogEventsList::userCanBitfield`:
  * This method implicitly //accepts// composite bitfields safely, as
    its logic handles multiple flags without skipping required checks.
* `ChangesList::userCan`:
  * This method delegates to `RevisionRecord::userCanBitfield` for
    non-log RC rows. This means that composite bitfields are unsafe
	here as well.

What:
* Eliminate code paths where composite bitfields were passed to methods
  that delegate to `RevisionRecord::userCanBitfield`.
* Add row-level access checks to `AbuseFilterPermissionManager`,
  separating row visibility from aspect-level permission checks.
  * These helpers could be moved to core in the future, but no other
    code seems to require this logic at the moment.
* This change does not modify core permission semantics. It only
  prevents unsafe composite bitfield usage.

Bug: T415584
Change-Id: I91469a210d3c9c2acbcc8701dfb278d8058ea9dd
Change-Id: Ifc9c5e43bcc6070e5a04c0ff7ac6008d73e32eea
Change-Id: Id2f3af127930e65264591698b548e3907058c929
Change-Id: I58932e7b3aa89f8e1f1099e15bf43d81e31b01a5
* grunt: 1.6.1 → 1.6.2
* grunt-legacy-log: 3.0.0 → 3.0.1
  * GHSA-f23m-r3pf-42rh
  * GHSA-r5fr-rjxr-66jc
* grunt-legacy-log-utils: 2.1.0 → 2.1.3
  * GHSA-f23m-r3pf-42rh
  * GHSA-r5fr-rjxr-66jc
* grunt-legacy-util: 2.0.1 → 2.0.2
  * GHSA-f23m-r3pf-42rh
  * GHSA-r5fr-rjxr-66jc
* lodash: 4.17.23 → 4.18.1
  * GHSA-f23m-r3pf-42rh
  * GHSA-r5fr-rjxr-66jc

Change-Id: I3eea72dfca5d7c3b0a798b0c7c69e6066c97e19a
Change-Id: I969a9f1fddde832a45c339e5f31aed0c17efbc1d
* GHSA-qx2v-qp2m-jg93

Change-Id: I04c8f9c18e4aea511b17aad0ba98acf3769d9a20
Change-Id: Ida90e408dcdf46ea9740f563445becf6fa681040
Change-Id: Idd74dca6a2baa0767d6f5453d7c111f63010c370
Change-Id: Ib335593d37d1be0db3471e2d2aef17dbd2e50d36
* GHSA-q3j6-qgpj-74h6
* GHSA-v39h-62p7-jpjc

Change-Id: Id43014aa18b4a12d1bc74148dd96287fdb9990dd
Change-Id: I7ba88294897faa9a68a043f50f63f9d0318ffad1
Change-Id: I281fafce5618e73220c07a310b85b72067cd552e
Change-Id: Ia973ec5e34d198b6a057e8fb7b1c0a6f6bfe3d9d
Change-Id: I940385727e6f98679f8f07ae46f7627e8f61e364
Change-Id: I974e0d3241a4326127d0c0cc9b38117dafeb35b4
Change-Id: Ie4ac2555409d542cfe499eade736e7593c049e08
CVE-2026-58027

Why:
* The QueryAbuseFilters API (action=query&list=abusefilters) returns
  the hit count for all filters, including private and protected ones,
  even when the requesting user lacks the necessary permissions. The
  Special:AbuseFilter UI correctly hides the hit count using
  canSeeLogDetailsForFilter(), but the API does not perform this check.

What:
* Gate the 'hits' field in the API response behind the same
  canSeeLogDetailsForFilter() permission check that the UI uses in
  AbuseFilterPager::formatValue().
* Add test coverage for hit count visibility with protected and hidden
  filters for users with varying permission levels.

Bug: T406954
Change-Id: Icd1a8e01366c2e8f4ed4cf0b3fdd3fca88725266
Change-Id: I19988519e9c680f4b62c8987d9da4313b6d09b70
Change-Id: I1288e86c666fd7bc78167cee6b1c90bc4ccc51d9
Change-Id: I44a6ae899917b2ed113212a131165f7c603838d9
Change-Id: Ic68680a644ecc1115738348872774a11fab55374
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.