Sync with upstream#27
Open
github-actions[bot] wants to merge 565 commits into
Open
Conversation
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
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.