[Wikidata-bugs] [Maniphest] T364539: Protocol-relative URL in sidebar now interpreted as title (Query Service link in Wikidata sidebar broken)
Bawolff added a comment. Also broke the techblog link on mediawiki.org TASK DETAIL https://phabricator.wikimedia.org/T364539 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Bawolff, Nikki, Addshore, WMDE-Fisch, Lydia_Pintscher, Aklapper, LucasWerkmeister, Danny_Benjafield_WMDE, Isabelladantes1983, Themindcoder, Adamm71, S8321414, Jersione, Hellket777, LisafBia6531, Astuthiodit_1, 786, Biggs657, karapayneWMDE, bwang, Invadibot, maantietaja, Juan90264, Alter-paule, NavinRizwi, Beast1978, Biaoo, Philoserf, ItamarWMDE, Un1tY, Akuckartz, Dringsim, Ironie, Hook696, Kent7301, joker88john, CucyNoiD, Nandana, alistair3149, Gaboe420, Amorymeltzer, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, KimKelting, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Wikidata-bugs, Mooeypoo, Hydriz, aude, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T340201: Use custom language code to find i18n XSS issues
Bawolff added a comment. Creating T347787 <https://phabricator.wikimedia.org/T347787> to brainstorm ideas about the Pager class hierarchy. I didn't create a brainstorming one for LogFormatter, as that case seems pretty hopeless. TASK DETAIL https://phabricator.wikimedia.org/T340201 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, Bawolff Cc: Bawolff, Daimona, Nikerabbit, Jdforrester-WMF, Fomafix, Lydia_Pintscher, sbassett, jhsoby, kostajh, matmarex, bd808, Michael, Aklapper, Lucas_Werkmeister_WMDE, Danny_Benjafield_WMDE, Cleo_Lemoisson, Astuthiodit_1, karapayneWMDE, Invadibot, Dylsss, Devnull, maantietaja, ItamarWMDE, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wong128hk, Luke081515, Wikidata-bugs, aude, Grunny, csteipp, Mbch331, Jay8g, Krenair, Legoktm ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T340201: Use custom language code to find i18n XSS issues
Bawolff added a comment. This also seems to be really demonstrating the value of phan taint check. So far it seems like most of the found issues are in some corner that phan-taint-check can't analyze - mustache templates (+ some skin stuff which I didn't look too closely at. Not sure if this is purely due to mustache or if there are additional complications) - LogFormatter subclasses - Pager class hierarchy. [There's some other one-off things that i think would be more straight forward to add to phan-taint-check] Maybe we should think about how to either refactor these code patterns so we can use phan-taint-check on them, or think of ways of making phan taint check better. TASK DETAIL https://phabricator.wikimedia.org/T340201 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, Bawolff Cc: Bawolff, Daimona, Nikerabbit, Jdforrester-WMF, Fomafix, Lydia_Pintscher, sbassett, jhsoby, kostajh, matmarex, bd808, Michael, Aklapper, Lucas_Werkmeister_WMDE, Danny_Benjafield_WMDE, Cleo_Lemoisson, Astuthiodit_1, karapayneWMDE, Invadibot, Dylsss, Devnull, maantietaja, ItamarWMDE, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wong128hk, Luke081515, Wikidata-bugs, aude, Grunny, csteipp, Mbch331, Jay8g, Krenair, Legoktm ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T209923: Surface hidden and "undefined" slots via a single slot view
Bawolff added a project: Multi-Content-Revisions. TASK DETAIL https://phabricator.wikimedia.org/T209923 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Tgr, Aklapper, daniel, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Naike, ItamarWMDE, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Ltrlg ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T106367: Generate BCP 47 conform language codes for the HTML attribute `lang`
Bawolff added a comment. Note: there are reports that this causes problem on ubuntu's version of firefox https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2012430 TASK DETAIL https://phabricator.wikimedia.org/T106367 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: cscott, Bawolff Cc: Bawolff, Jdforrester-WMF, Volker_E, Phispi, Jonas, gerritbot, Aklapper, Fomafix, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, Af420, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, MuhammadShuaib, LNDDYL, Psychoslave, Wikidata-bugs, aude, Arrbee, KartikMistry, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T289760: Evaluate Oxigraph as alternative to Blazegraph
Bawolff added a comment. In T289760#7874365 <https://phabricator.wikimedia.org/T289760#7874365>, @DD063520 wrote: > Hi, I saw the document, but I'm a bit confused. Because the criteria are basically checked for the shortlisted solutions. But in which part do you explain why for example Oxigraph was not shortlisted. I did not read the full document from start maybe i miss something, it's just to understand It was on page 35. They basically said it was too early in its development. TASK DETAIL https://phabricator.wikimedia.org/T289760 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Bawolff, DD063520, MPhamWMF, Jerven, AndySeaborne, BenAtOlive, Justin0x2004, Izno, Gehel, Thadguidry, Tpt, So9q, Aklapper, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T286239: Make tlh-latn and tlh-piqd a valid monolingual string language
Bawolff added a comment. In T286239#7491899 <https://phabricator.wikimedia.org/T286239#7491899>, @Amire80 wrote: > This language code is valid, but Klingon has a history of copyright litigation, so I'd say this should also have some legal advice, which I cannot provide. IANAL, but from what i could google, the history of litigation seems to be https://torrentfreak.com/klingon-language-copyright-battle-ends-for-now-170113/ where the matter at hand wasn't really about the Klingon language itself but a more typical derrivative fictional work, and all references to the klingon language got excluded from the final case. I know the internet isn't the best place for legal advice, but this seems really overly cautious when most of the internet seems to think that conlangs cannot be copyrighted, and there doesn't seem to be a single case ever having happened about the subject. TASK DETAIL https://phabricator.wikimedia.org/T286239 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Bawolff, Naseweis520, Mahir256, Lucas_Werkmeister_WMDE, Manuel, Nikki, Mbch331, Amire80, Shisma, Esc3300, jhsoby, Ameisenigel, Aklapper, Loominade, Jersione, Hellket777, mrephabricator, LisafBia6531, Astuthiodit_1, 786, Biggs657, karapayneWMDE, Invadibot, maantietaja, Juan90264, Alter-paule, Beast1978, ItamarWMDE, Un1tY, Akuckartz, Hook696, Kent7301, RhinosF1, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T319219: Wikibase gives deprecated warnings on php 8.1
Bawolff created this task. Bawolff added projects: MediaWiki-extensions-WikibaseClient, MediaWiki-extensions-WikibaseRepository, PHP 8.1 support. Restricted Application added subscribers: Base, Aklapper. TASK DESCRIPTION Wikibase gives deprecated warnings on php 8.1. In addition to the general problem that this causes for users who have E_DEPRECATED on, it also makes phpunit tests fail on php 8.1, including extensions that have tests that depend on it, such as Math which is bundled with mediawiki. Having all extensions bundled with MediaWiki pass unit tests on php8.1 would help reassure users that we support php 8.1, which this is blocking. PHPUnit output: INFO:quibble.commands:>>> Start: PHPUnit unit tests PHPUnit unit tests composer phpunit:unit -- --exclude-group Broken,ParserFuzz,Stub > phpunit --colors=always --testsuite=core:unit,extensions:unit,skins:unit '--exclude-group' 'Broken,ParserFuzz,Stub' Deprecated: Return type of Wikibase\Lexeme\Domain\Model\FormSet::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/extensions/WikibaseLexeme/src/Domain/Model/FormSet.php on line 74 PHP Deprecated: Return type of Wikibase\Lexeme\Domain\Model\FormSet::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/extensions/WikibaseLexeme/src/Domain/Model/FormSet.php on line 74 Deprecated: Wikibase\Lexeme\Domain\Model\FormId implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /workspace/src/extensions/WikibaseLexeme/src/Domain/Model/FormId.php on line 15 PHP Deprecated: Wikibase\Lexeme\Domain\Model\FormId implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /workspace/src/extensions/WikibaseLexeme/src/Domain/Model/FormId.php on line 15 Deprecated: Return type of Wikibase\DataModel\Term\TermList::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/extensions/Wikibase/lib/packages/wikibase/data-model/src/Term/TermList.php on line 41 Deprecated: Return type of Wikibase\DataModel\Term\TermList::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/extensions/Wikibase/lib/packages/wikibase/data-model/src/Term/TermList.php on line 64 PHP Deprecated: Return type of Wikibase\DataModel\Term\TermList::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/extensions/Wikibase/lib/packages/wikibase/data-model/src/Term/TermList.php on line 41 PHP Deprecated: Return type of Wikibase\DataModel\Term\TermList::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/extensions/Wikibase/lib/packages/wikibase/data-model/src/Term/TermList.php on line 64 Deprecated: Wikibase\Lexeme\Domain\DummyObjects\NullFormId implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /workspace/src/extensions/WikibaseLexeme/src/Domain/DummyObjects/NullFormId.php on line 12 PHP Deprecated: Wikibase\Lexeme\Domain\DummyObjects\NullFormId implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /workspace/src/extensions/WikibaseLexeme/src/Domain/DummyObjects/NullFormId.php on line 12 PHP Deprecated: Wikibase\Lexeme\Domain\DummyObjects\DummyFormId implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /workspace/src/extensions/WikibaseLexeme/src/Domain/DummyObjects/DummyFormId.php on line 10 Deprecated: Wikibase\Lexeme\Domain\DummyObjects\DummyFormId implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /workspace/src/extensions/WikibaseLexeme/src/Domain/DummyObjects/Dum
[Wikidata-bugs] [Maniphest] T313564: Bump onoi/message-reporter in vendor.git to 1.4.2 for php 8 support
Bawolff added a comment. Hmm, i know general practice is to require exact version in vendor.git, but I wonder if this is a case where it would be acceptable to `"1.4.2|1.4.1"` since both versions are essentially identical, and its just which version of php they are marked as supporting TASK DETAIL https://phabricator.wikimedia.org/T313564 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: JeroenDeDauw, Reedy, Aklapper, Bawolff, ItamarWMDE, Akuckartz, DannyS712, lucamauri, Gq86, Wikidata-bugs, Nikerabbit, Jdforrester-WMF, MaxSem ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T313564: Bump onoi/message-reporter in vendor.git to 1.4.2 for php 8 support
Bawolff added a subscriber: JeroenDeDauw. Bawolff added a comment. This is hard because the commit that added support for php 8, marked it as no longer supporting php 7.2. And we want to support both in these tests :( TASK DETAIL https://phabricator.wikimedia.org/T313564 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: JeroenDeDauw, Reedy, Aklapper, Bawolff, ItamarWMDE, Akuckartz, DannyS712, lucamauri, Gq86, Wikidata-bugs, Nikerabbit, Jdforrester-WMF, MaxSem ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T313564: Bump onoi/message-reporter in vendor.git to 1.4.2 for php 8 support
Bawolff created this task. Bawolff added projects: PHP 8.0 support, MediaWiki-extensions-WikibaseRepository. TASK DESCRIPTION vendor.git currently requires version 1.4.1 of onoi/message-reporter. This is breaking tests on php8, as you need 1.4.2 for php 8 support Wikibase says it needs ~1.4, so updating this should be fine. TASK DETAIL https://phabricator.wikimedia.org/T313564 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Reedy, Aklapper, Bawolff, ItamarWMDE, Akuckartz, DannyS712, lucamauri, Gq86, Wikidata-bugs, Nikerabbit, Jdforrester-WMF, MaxSem ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] [Created] T248278: Wikibase doesn't respect Kartographer's addExtraCSPSrc
Bawolff created this task.
Bawolff added projects: MediaWiki-extensions-WikibaseRepository, Maps
(Kartographer), ContentSecurityPolicy.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
In 889716e13798
<https://phabricator.wikimedia.org/rEKAR889716e13798b98949da3ee306a3dcf5f03eeda8>
Kartographer was changed to automatically add the map server to the CSP source
list for pages that include a map on them. However this doesn't seem to work
for Wikidata, due to
`Wikibase\Repo\ParserOutput\GlobeCoordinateKartographerDataUpdater::updateParserOutput`
not copying that data over.
This wouldn't affect anything in production (Because CSP is not in use yet,
but also the plan is to whitelist all of *.wikimedia.org just generally).
However, this is breaking things on beta wiki.
My suggested fix would be:
diff --git
a/repo/includes/ParserOutput/GlobeCoordinateKartographerDataUpdater.php
b/repo/includes/ParserOutput/GlobeCoordinateKartographerDataUpdater.php
index a6963cc409..6a79c92ba5 100644
--- a/repo/includes/ParserOutput/GlobeCoordinateKartographerDataUpdater.php
+++ b/repo/includes/ParserOutput/GlobeCoordinateKartographerDataUpdater.php
@@ -81,6 +81,11 @@ class GlobeCoordinateKartographerDataUpdater implements
StatementDataUpdater {
$parserOutput->addModules(
$kartographerParserOutput->getModules() );
$parserOutput->addModuleStyles(
$kartographerParserOutput->getModuleStyles() );
+ $srcs = $kartographerParserOutput->getExtraCSPDefaultSrcs();
+ foreach( $srcs as $src ) {
+ $parserOutput->addExtraCSPDefaultSrc( $src );
+ }
+
$parserOutput->setExtensionData(
'kartographer',
$kartographerParserOutput->getExtensionData(
'kartographer' )
However, I'm not sure if that would work during preview. I also haven't
tested this as of yet.
Alternatively, it may make sense to use
`ParserOutput::mergeInternalMetaDataFrom`, so that this is less coupled to
internal implementation details.
TASK DETAIL
https://phabricator.wikimedia.org/T248278
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Bawolff
Cc: hoo, Aklapper, Bawolff, Alilje, darthmon_wmde, Nabetaro, DannyS712,
Nandana, MSantos, Lahi, Gq86, Looniverse, GoranSMilovanovic, QZanden,
Orienteerix, LawExplorer, Ddproxy, _jensen, rosalieper, JGirault, Scott_WUaS,
phabyogi, GAllegre, Susannaanas, ferdbold, lxbarth, Planemad, Wikidata-bugs,
aude, Yurik, Jdforrester-WMF, Mbch331, Rxy, Jay8g
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240884: Standalone service to evaluate user-provided regular expressions
Bawolff added a comment. In T240884#5796687 <https://phabricator.wikimedia.org/T240884#5796687>, @Joe wrote: > I think the main question to answer is "does it make sense to create a safe regex evaluation service?". > I think in a void the answer is "no". It could make sense to create a small C++ program wrapping the main re2 functionality and shell out to it from php. > On the other hand, we have to consider the wikimedia infrastructure for this and there are two counterpoints to be made: > > - Is this a service we can only expect MediaWiki to call? If not, that's a point in favour of creating a separate service > - Shelling out for us works well by using a combination of firejail and cgroups creation that won't work well in the future with cgroups v2 and containerization > - Performance might not be extremely relevant > > Now on the last point: this proposal seems to worry a lot about performance, but I see no performance requirement spelled out. Without more context, both the choice of shelling out vs and RPC service, and the proposal to use gRPC for said service seem to me like premature optimizations. > So my questions are: > > - What is the 95th percentile of latency in validating all the constraint on an item when editing it? > - What is the average, median and max number of regexes we need to validate per item? > > Without answering those questions, we would just make choices by principle, while I think we should have a more pragmatic approach. I think there is a question of whether we are just going to have the wikidata thing use this, or eventually all user (including admin) provided regexes? If we also eventually move AbuseFilter & SpamBlacklist to this, I could see performance possibly being a concern since these features often involve running quite a large number of regexes that block saving a page until they complete (That said, I don't have any specific numbers beyond a gut feeling that it is so). TASK DETAIL https://phabricator.wikimedia.org/T240884 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Bawolff, Joe, WMDE-leszek, Volans, sbassett, Krinkle, Agabi10, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Ladsgroup, darthmon_wmde, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, _jensen, rosalieper, D3r1ck01, Scott_WUaS, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T176312: Don’t check format constraint via SPARQL (safely evaluating user-provided regular expressions)
Bawolff added a comment. Just as an aside, the dirt simple solution here would be to shell out to `grep -p` (or even just to php fed just the preg_match call) and rely on limit.sh to prevent undue resourse usage. TASK DETAIL https://phabricator.wikimedia.org/T176312 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: EBernhardson, Bawolff, abian, Addshore, Ladsgroup, Milimetric, Nikerabbit, Anomie, Smalyshev, tstarling, daniel, GWicke, Joe, Lucas_Werkmeister_WMDE, Aklapper, darthmon_wmde, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, merbst, LawExplorer, _jensen, rosalieper, Agabi10, D3r1ck01, Scott_WUaS, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T223776: Create Wikidata autocomplete gadget for external entities
Bawolff closed subtask T223840: Can/should *.wmflabs.org be added to the default-src Content Security Policy? as Declined. TASK DETAIL https://phabricator.wikimedia.org/T223776 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Danmichaelo, Bawolff Cc: Abbe98, Salgo60, Pintoch, Lea_Lacroix_WMDE, Aklapper, Danmichaelo, darthmon_wmde, Ferenczy, sarhan.alaa, Samuditha24, IM3847, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, Chicocvenancio, MichaelSchoenitzer_WMDE, QZanden, dachary, LawExplorer, Jogi_don, _jensen, rosalieper, D3r1ck01, Scott_WUaS, Wikidata-bugs, Jdlrobson, aude, Ricordisamoa, Sjoerddebruin, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org
Bawolff added a comment. So I guess the next question is, where to set the CSP headers. My guess would be in `sub cluster_fe_deliver` of `text-frontend.inc.vcl.erb`, but I'm really not sure if that is the correct place. TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Lucas_Werkmeister_WMDE, Aklapper, Bawolff, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org
Bawolff added a comment. So revised suggested CSP header: For everything except in the polestar directory: default-src 'self' data:; style-src 'unsafe-inline' data: 'self'; img-src data: 'self' upload.wikimedia.org commons.wikimedia.org; media-src data: 'self' upload.wikimedia.org commons.wikimedia.org; script-src 'report-sample' https://query.wikidata.org/js/ blob:; connect-src meta.wikimedia.org/w/api.php www.wikidata.org/w/api.php 'self' query.wikidata.org; object-src 'none'; report-uri https://www.wikidata.org/w/api.php?action=cspreport=none=wdqs For the polestar directory: default-src 'self' data:; style-src 'unsafe-inline' data: 'self'; img-src data: 'self' upload.wikimedia.org commons.wikimedia.org; media-src data: 'self' upload.wikimedia.org commons.wikimedia.org; script-src 'report-sample' https://query.wikidata.org/polestar/scripts/ 'unsafe-eval'; object-src 'none'; sandbox allow-scripts; report-uri https://www.wikidata.org/w/api.php?action=cspreport=none=wdqs-polestar This will cause the bookmark feature of polestar to be disabled (Is that acceptable?). It will also break the import data option, but that doesn't look like it works anyways, and isn't shown in the normal workflow. TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Lucas_Werkmeister_WMDE, Aklapper, Bawolff, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, LawExplorer, Salgo60, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org
Bawolff added a comment. Polestar also has a button to load datasets from http://ec2-52-1-38-182.compute-1.amazonaws.com:8753 - which seems a bit suspect from a privacy policy perspective... TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Lucas_Werkmeister_WMDE, Aklapper, Bawolff, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, LawExplorer, Salgo60, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org
Bawolff added a comment. So if I was ignoring polestar (aka graph builder mode) the ideal CSP would be something like: default-src 'self' data:; style-src 'unsafe-inline' data: 'self'; img-src data: 'self' upload.wikimedia.org commons.wikimedia.org; media-src data: 'self' upload.wikimedia.org commons.wikimedia.org; script-src 'report-sample' https://query.wikidata.org/js/ blob:; connect-src meta.wikimedia.org www.wikidata.org 'self'; object-src 'none'; report-uri https://www.wikidata.org/w/api.php?action=cspreport=none TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Lucas_Werkmeister_WMDE, Aklapper, Bawolff, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org
Bawolff added a comment. So investigating this a bit further: - embed.html would ideally have its script in a separate file - Move the current usages of JSONP with www.wikidata.org to CORS - polestar uses angular, from what I understand, angular can be used to bypass CSP TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Lucas_Werkmeister_WMDE, Aklapper, Bawolff, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T238618: Adopt a CSP policy for query.wikidata.org
Bawolff created this task. Bawolff added projects: ContentSecurityPolicy, Wikidata-Query-Service. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION As part of the effort to put CSP on all the things, as well as to help mitigate the risk of an XSS in the query service (like T233213 <https://phabricator.wikimedia.org/T233213>), I think it would be prudent to adopt a CSP policy for WDQS. Looking at query.wikidata.org, at first glance the GUI appears to be a fairly modern JS application that mostly avoids inline javascript - and where there is inline js (like in embed mode), it appears to be mostly static scripts. Anyways, i need to investigate a little more, but at first glance, it looks like it would be fairly easy to adopt a CSP policy that would increase the security of WDQS without any negative side effects. TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Aklapper, Bawolff, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T208329: Gadget with SPARQL services collides with Content Security Policy?
Bawolff added a comment. In T208329#4727241 <https://phabricator.wikimedia.org/T208329#4727241>, @Smalyshev wrote: > Not sure where that error is coming from - SPARQL responses have `access-control-allow-origin: *`. Maybe it's something in Mediawiki settings? CORS and CSP are separate mechanisms. This error will come from the Content-Security-Policy header on the wiki site (and not any header on the SPARQL response) TASK DETAIL https://phabricator.wikimedia.org/T208329 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Bawolff, EBjune, Smalyshev, Addshore, Aklapper, Karima, darthmon_wmde, JFishback_WMF, Dsharpe, DannyS712, Nandana, sbassett, Lahi, Gq86, GoranSMilovanovic, QZanden, HJiang-WMF, LawExplorer, _jensen, rosalieper, dpatrick, Wong128hk, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, DerHexer, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Rxy, Jay8g, Krenair, Legoktm, chasemp ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T222681: WikidataPageBanner uses a blacklist of skin names to decide 'prebodyhtml' support instead of sane feature detection
Bawolff created this task.
Bawolff added projects: Timeless, Wikidata-Page-Banner, Technical-Debt.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
It appears that wikidata page banner uses an (essentially) undocumented* skin
api ('prebodyhtml') that is only implemented in Vector and Minerva.
*It is technically documented, but there's the strong implication it is a
skin-specific hack to make VectorBeta work and not meant for general usage nor
expected to be implemented by skins in general.
It uses a blacklist to use an alternative approach in all other skins that (I
assume) the extension author could think of.
This is a bad approach. If nothing else, given this api basically only exists
in Vector and is not documented as something skins are expected to implement,
it should be using a whitelist of good skins, since basically no skins
implement it.
Better would be to have some sort of class constant if the api is supported,
so skins can do feature detection.
Even better would be, if the feature is actually useful and a good idea,
would be to document/standardize it so that all skins are expected to implement
it (What this entails in our context is debatable. At a bare minimum it should
be in the official "example" skin and perhaps have a more explicit code comment
in skins/SkinTemplate.php.
The original context that this came up in is that WikidataPageBanner does not
seem to work in Timeless and some other skins. Arguably one could band-aid this
by just adding Timeless to the blacklist, but that seems like just pushing the
tech-debt down the road.
TASK DETAIL
https://phabricator.wikimedia.org/T222681
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Bawolff
Cc: Bawolff, alaa_wmde, Nandana, Chief_Mike, CycloneIsaac, Lahi, Gq86,
GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Framawiki, _jensen,
rosalieper, Evad37, Izno, MGChecker, Feldo, Wong128hk, Luke081515, Unapersona,
Wikidata-bugs, aude, Dinoguy1000, waldyrious, RandomDSdevel, Lydia_Pintscher,
Isarra, Mbch331, Jay8g, Ltrlg
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T218568: Allow CORS from query.wikidata.org to production wikis
Bawolff added a comment. Reading https://meta.wikimedia.org/w/api.php?action=help=shortenurl - doesn't seem to require a CSRF token, so I'm not sure that CORS is needed here? (more specifically, you can use the generic origin=* I think). Although query.wikidata.org is fairly trusted, its still nice to reduce exposure by limiting CORS in places that don't strictly need it. TASK DETAIL https://phabricator.wikimedia.org/T218568 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Bawolff, Aklapper, Lucas_Werkmeister_WMDE, alaa_wmde, ET4Eva, Nandana, sbassett, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, Jayprakash12345, QZanden, EBjune, HJiang-WMF, Zoranzoki21, merbst, LawExplorer, Avner, DatGuy, Devwaker, Niklitov, Gehel, _jensen, Urbanecm, rosalieper, JEumerus, Jonas, Ananthsubray, FloNight, Xmlizer, dpatrick, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, Snowolf, aude, Tobias1984, GWicke, Dcljr, Stype_and_Co.-WMF, Manybubbles, Jalexander, Parent5446, Anomie, Grunny, Jdforrester-WMF, MaxSem, csteipp, Matanya, Mbch331, Rxy, Jay8g, Krenair, Legoktm, chasemp ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Policy] T212787: Wikidata slack channel token in public config file
Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)". TASK DETAILhttps://phabricator.wikimedia.org/T212787EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: hoo, RazShuty, Greta_Doci_WMDE, Michael, Ladsgroup, WMDE-leszek, Lydia_Pintscher, Lucas_Werkmeister_WMDE, Tarrow, Addshore, MaxSem, Vgutierrez, sbassett, Aklapper, Bawolff, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, HJiang-WMF, LawExplorer, _jensen, D3r1ck01, Jonas, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, csteipp, Mbch331, Rxy, Jay8g, Legoktm, chasemp___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T210634: Scribunto test “LuaStandalone: SecurityTests[1]: CVE-2014-5461” failing in Wikibase CI builds
Bawolff added a comment. The gci task is already accepted - we cant force the student to do more work (we can of course ask nicely) In T210634#4782783, @Anomie wrote: Apparently the test added for T209232: Add a unit test to Scribunto testing it is not vulnerable to CVE-2014-5461 is sometimes running out of allowed memory (set by ulimit most likely) before it runs out of Lua stack space (a constant set in Lua's C code), so it's giving a different error from the one that was expected. If nothing else we could revert rELUA7a7f5226765e: Adding a unit test for CVE-2014-5461 in Scribunto. and let them try again on that task. TASK DETAILhttps://phabricator.wikimedia.org/T210634EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, Anomie, Aklapper, Lucas_Werkmeister_WMDE, Nandana, A.S.Kochergin, God, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, SundanceRaphael, _jensen, D3r1ck01, Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, hashar___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T208329: Gadget with SPARQL services and the Content Security Policy ?
Bawolff added a comment. Hi, So query.wikidata.org is allowed from the CSP policy. For other domains, we are planning to have a process where individual users can specify that they allow other sources. The details aren't entirely worked out yet, but some sort of solution to this problem will definitely be done (See T208188 for details)TASK DETAILhttps://phabricator.wikimedia.org/T208329EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, EBjune, Smalyshev, Addshore, Aklapper, Karima, Nandana, sbassett, charlotteportero, Lahi, Gq86, GoranSMilovanovic, QZanden, HJiang-WMF, LawExplorer, dpatrick, Wong128hk, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Rxy, Jay8g, Krenair, Legoktm, chasemp___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T196892: Raw HTML in page descriptions
Bawolff added a comment. I personally think we should document the situation carefully, but ultimately this is clients responsibilityTASK DETAILhttps://phabricator.wikimedia.org/T196892EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, Aklapper, Lydia_Pintscher, Tgr, Lahi, Gq86, GoranSMilovanovic, QZanden, HJiang-WMF, LawExplorer, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, Jdforrester-WMF, MaxSem, csteipp, Mbch331, Jay8g, Legoktm, chasemp___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T183020: Investigate the possibility to release Wikidata queries
Bawolff closed subtask T190875: Security review for Wikidata queries data release proposal as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T183020EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: EBjune, mkroetzsch, Smalyshev, DarTar, leila, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Avner, Wikidata-bugs, aude, Capt_Swing, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T190875: Security review for Wikidata queries data release proposal
Bawolff closed this task as "Resolved".Bawolff claimed this task.Bawolff added a comment. I think this is ok, and I have no objections, with the caveat that (imo), security's role should be ensuring that stuff meets a certain standard or is safe against a certain threat model. I don't entirely feel confident that I'm competent to review something where the criteria of what we're trying to protect against is unspecified. That said, as far as I can tell, the proposal sounds reasonable. If we intend to do this again in the future, we should fully disclose that we will release redacted logs, on the query.wikidata.org footer.TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: JBennett, Adrian_Bielefeldt, Bawolff, APalmer_WMF, Aklapper, DarTar, mkroetzsch, EBjune, Smalyshev, leila, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Avner, dpatrick, ZhouZ, Luke081515, Wikidata-bugs, aude, Capt_Swing, JanZerebecki, Slaporte, csteipp, Mbch331, Jay8g, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal
Bawolff added a comment. Sorry for the delay, this kind of got preempted by t194204 but is now next on my todo list. As an aside - this sort of thing traditionally doesnt require security team sign off (afaik) nor have we reviewed things like this in the past - historically its been legal and maybe analytics only. As far as I know security team has no criteria for evaluating this sort of thing (beyond ensuring that its not blantently outputting PII) so Im mostly planning to check that it implementsthe properties specified in the description on the linked wikipage. I hope that meets what everyone is looking for.TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: JBennett, Adrian_Bielefeldt, Bawolff, APalmer_WMF, Aklapper, DarTar, mkroetzsch, EBjune, Smalyshev, leila, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Avner, dpatrick, ZhouZ, Luke081515, Wikidata-bugs, aude, Capt_Swing, JanZerebecki, Slaporte, csteipp, Mbch331, Jay8g, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal
Bawolff added a comment. Sorry, im on vacation until Monday. Perhaps someone else on the security team can take a look or failing that ill be back on monday (Thank you for your patience, i know this has been delayed multiple times)TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Adrian_Bielefeldt, Bawolff, APalmer_WMF, Aklapper, DarTar, mkroetzsch, EBjune, Smalyshev, leila, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Avner, dpatrick, ZhouZ, Luke081515, Wikidata-bugs, aude, Capt_Swing, JanZerebecki, Slaporte, csteipp, Mbch331, Jay8g, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T195618: wikidatawiki.wb_terms missing label and descriptions for some languages
Bawolff added a comment. e78328eab0e7 was the commit i found, which made it look like it was disabled (Guessing by commit message. I'm not actually familiar with the feature or what's going on)TASK DETAILhttps://phabricator.wikimedia.org/T195618EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, Addshore, Aklapper, MusikAnimal, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173339: Categories tracking pages with wikidata links are not updated when items on Wikidata are modified
Bawolff added a comment. A good way to test this theory would be to find a page affected by this and see if page_links_updated timestamp is greater than the timestamp on the wikidata edit. The timestamp on page_links_update should be the time that the page was finished being parsed (i wonder why its not start of parse?) So if its using an old cached ParserCache object than the timestamp should be from before the wikidata edit (or perhaps the same time if there is some sort of race condition).TASK DETAILhttps://phabricator.wikimedia.org/T173339EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, daniel, aaron, Mike_Peel, zhuyifei1999, Lea_Lacroix_WMDE, Lydia_Pintscher, Yann, Agabi10, thiemowmde, Aklapper, Jarekt, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Poyekhali, Wong128hk, Wikidata-bugs, aude, El_Grafo, Dinoguy1000, Steinsplitter, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal
Bawolff added a comment. Question: Looking at https://github.com/Wikidata/QueryAnalysis/blob/master/tools/extractAnonymized.py, at first glance, it looks like the string handline code wouldn't handle edge cases properly e.g. "foo\"bar" "foo'bar" ? (I only skimmed the code, may have misunderstood) We have a list of query types ordered by frequency. However, there are millions of query types, and the most frequent are those created by bots. I can dig up a pointer to the local file where we have it, if this is what you want. If you are interested in a broader analysis of the data, you could take a look at a recent workshop paper of ours: https://iccl.inf.tu-dresden.de/web/Inproceedings3196/en It has detailed statistics of SPARQL feature distributions and discusses some findings. Ok, that's good enough that you did that I think. The main point of the question was to ensure that you had a good idea of the type of data in the data set (i.e. We aren't just releasing data we've never actually looked at)TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, APalmer_WMF, Aklapper, DarTar, mkroetzsch, EBjune, Smalyshev, leila, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Avner, dpatrick, ZhouZ, Luke081515, Mpaulson, Wikidata-bugs, aude, Capt_Swing, jayvdb, JanZerebecki, Slaporte, csteipp, Mbch331, Jay8g, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal
Bawolff added a comment. Hi, So first of all, we'd like to see the code that does the query normalization. Second, could this have a summary of the types of queries we expect to be most common in the data set. I appreciate there will be a very long tail here, but having a summary of the most common types (broadly speaking) ensures that we have a good understanding of the type of data we expect the data-set to contain.TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, APalmer_WMF, Aklapper, DarTar, mkroetzsch, EBjune, Smalyshev, leila, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Avner, dpatrick, ZhouZ, Luke081515, Mpaulson, Wikidata-bugs, aude, Capt_Swing, jayvdb, JanZerebecki, Slaporte, csteipp, Mbch331, Jay8g, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T190875: Security review for Wikidata queries data release proposal
Bawolff added subscribers: APalmer_WMF, Bawolff.Bawolff added projects: Privacy, WMF-Legal.Bawolff added a comment. I suspect this is more something that should have a privacy review from #wmf-legal than a security review.TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, APalmer_WMF, Aklapper, DarTar, mkroetzsch, EBjune, Smalyshev, leila, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Avner, dpatrick, ZhouZ, Luke081515, Mpaulson, Wikidata-bugs, aude, Capt_Swing, jayvdb, JanZerebecki, Slaporte, csteipp, Mbch331, Jay8g, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T186726: Security review WikibaseLexeme extension
Bawolff closed this task as "Resolved".Bawolff added a comment. Yep, you are good.TASK DETAILhttps://phabricator.wikimedia.org/T186726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Jakob_WMDE, Jonas, gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Ladsgroup, thiemowmde, Lydia_Pintscher, WMDE-leszek, Versusxo, Majesticalreaper22, Ahmed123, Tamgue, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, Cinemantique, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, LawExplorer, Lewizho99, Maathavan, dpatrick, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T168260: Deploy WikibaseLexeme extension on Wikimedia cluster
Bawolff closed subtask T186726: Security review WikibaseLexeme extension as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T168260EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Addshore, Aklapper, daniel, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T189491: Prevent clickjacking in the Wikibase UI
Bawolff added a comment. I've actually been thinking about this recently. MediaWiki is doing a subpar job with clickjacking in general. I'm now thinking that resource loader should in general just refuse to load any JS if the page is in a frame.TASK DETAILhttps://phabricator.wikimedia.org/T189491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Lydia_Pintscher, WMDE-leszek, Bawolff, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T186726: Security review WikibaseLexeme extension
Bawolff added a comment. re: FormIdFormatter and SenseIdFormatter - I thought they might later be extended to a real implementation, which is why I was concerned, but as long as its just a dummy implementation that's eventually going away, that's all cool. re: click-jacking: Yeah, it really is a wikidata issue. It does not block deployment of wikibaselexeme. As long as someone intends to look into the issue, I'm happy. comma-separator is a message from core, and intentionally contains HTML (but no wiki syntax). As far as I can see we are using it correctly. Yes, we are aware messages with HTML are problematic, and we avoid it whenever possible. In MediaWiki core, that message is always used as wfMessage( 'comma-separator' )->escaped(); WikibaseLexeme should similarly escape it. (In mediawiki core, the wfMessage()->escaped() format does not double encode entities, so stays as after escaping). So I'd still like to see the comma-separator thing changed (which is very a minor issue), but otherwise this looks good and is good to go.TASK DETAILhttps://phabricator.wikimedia.org/T186726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Jakob_WMDE, Jonas, gerritbot, Aklapper, Lucas_Werkmeister_WMDE, Ladsgroup, thiemowmde, Lydia_Pintscher, WMDE-leszek, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, Cinemantique, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, LawExplorer, Lewizho99, Maathavan, dpatrick, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T186726: Security review WikibaseLexeme extension
Bawolff moved this task from In Progress to Awaiting remediation on the Security-Reviews board.Bawolff added a comment. Review of WikidataLexeme & php-vuejs-templating (To be clear, I didn't look at vue.js in general, since that was already reviewed by Darian afaik). "FormIdFormatter.php" line 69 & "SenseIdFormatter.php" line 73 - It looks like this is not properly escaped. However, it also looks like this is just a couple hard coded examples. Kind of confused by this class tbh. "SensesView.php" line 127 - $sense->getId()->getSerialization() - should be html escaped I think. "FormsView.php" line 86 - $this->textProvider->get( 'comma-separator' ) - Please avoid using messages as raw html in new code. [This may be an issue with Wikidata in general] ClickJacking: Since this allows edit interaction directly on wikipage, it should take steps to prevent click jacking. Either _javascript_ should detect when the page is being framed, and refuse to load the editing related js code (Since the editing related code only happens if js is enabled, its safe to detect this condition in JS), or the extension can call OutputPage::preventClickjacking() (Which will totally disables frames altogether for both js and non-js users). In php-vuejs Its unclear to me if DomDocument::loadHtml processes external entities in modern PHP. https://www.mediawiki.org/wiki/XML_External_Entity_Processing implies that at least in older versions of PHP this was a problem. For the avoidance of doubt, can we wrap the call to loadHtml with libxml_disable_entity_loader just in case per https://www.mediawiki.org/wiki/XML_External_Entity_Processing . TASK DETAILhttps://phabricator.wikimedia.org/T186726WORKBOARDhttps://phabricator.wikimedia.org/project/board/944/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Lucas_Werkmeister_WMDE, Ladsgroup, thiemowmde, Lydia_Pintscher, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, EBjune, LawExplorer, dpatrick, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T186726: [WIP] Security review WikibaseLexeme extension
Bawolff added a comment. Just to confirm this is ready for review? The [WIP] in the title of the bug confuses me. p.s. in regards to Please link or describe setup process for setting up a test environment. @WMDE-leszek, can you help with this? Don't worry about that. Its a MW extension, I only need instructions if the setup is super weird.TASK DETAILhttps://phabricator.wikimedia.org/T186726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Lucas_Werkmeister_WMDE, Ladsgroup, thiemowmde, Lydia_Pintscher, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, EBjune, LawExplorer, dpatrick, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T184812: Enable constraint result caching on Wikidata
Bawolff added a comment. Php considering "0" to be false strikes again!TASK DETAILhttps://phabricator.wikimedia.org/T184812EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, BawolffCc: Bawolff, greg, Ladsgroup, jcrespo, Marostegui, TerraCodes, Stashbot, Liuxinyu970226, Jonas, Aklapper, gerritbot, Lucas_Werkmeister_WMDE, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, HJiang-WMF, LawExplorer, Lewizho99, Maathavan, Agabi10, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, Jalexander, ArielGlenn, Parent5446, Anomie, Grunny, He7d3r, csteipp, Mbch331, Jay8g, Legoktm, mmodell___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Claimed] T186726: [WIP] Security review WikibaseLexeme extension
Bawolff claimed this task. TASK DETAILhttps://phabricator.wikimedia.org/T186726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Lucas_Werkmeister_WMDE, Ladsgroup, thiemowmde, Lydia_Pintscher, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, EBjune, LawExplorer, dpatrick, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff added a comment. So core is fixed now, so we should be all clear to go ahead with the fix in wikidataTASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff added a comment. Fix for gender at https://gerrit.wikimedia.org/r/398772TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, CXuesong, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff added a comment.
I don’t think we can do that – {{GENDER}} needs the unescaped username. Otherwise we’ll address these users with the wrong gender. (I tried it out locally, {{GENDER:*asterisk|he|she|they}} produces “she” while {{GENDER:asterisk|he|she|they}} produces “they”.)
And weirdly enough, {{GENDER:User:asterisk|he|she|they}} produces she.TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, CXuesong, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff added a comment. Hmm. Maybe thats a bug in GENDER: i would expect it to normalize titles.TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Cpaulf30, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff added a comment.
In T182800#3835432, @Lucas_Werkmeister_WMDE wrote:
Why is this even being parsed as a list, anyways? The plain text of the message is:
Restore revision 597045630 by [[Special:Contributions/*Youngjin|{{GENDER:*Youngjin|*Youngjin}}]]
There’s no * anywhere near the beginning of a line, and yet a list is emitted. This can also be reproduced outside of this message, e. g. with foo{{GENDER:|*bar}}. Is that a bug of {{GENDER}}?
This is a well known feature of parser functions (That they add newlines). The behaviour is very controversial, but is probably here to stay for back compatibility if nothing else. See T14974
Alternative fix: wrap the user name in .
Just use the wfEscapeWikitext() global function (Defined in includes/GlobalFunctions.php), that's the standard solution the rest of MediaWiki uses.
:, #, <, >, [, ], {, } are not allowed in usernames.
' appears to get escaped.
& is allowed in usernames, and in fact MediaWiki seems to treat and " as the same user everywhere, so I assume allowing HTML entities in usernames is a feature(?). However, “double HTML entities” like quot; are not allowed.
Well you've also got percent encoding behaves weirdly in usernames. Some parts of MediaWiki use the '#' to make "fake" users (Especially the blocking code), but that's not relavent in this context. at the beginning of a line generates an . Urls cause all sorts of weird stuff to happen (But not inside a link). So do things like __TOC__, and magic links (RFC123) if they are enabled.TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Cpaulf30, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Policy] T164948: DoS attack vector in the WikibaseQualityConstraints extension
Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)". TASK DETAILhttps://phabricator.wikimedia.org/T164948EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, BawolffCc: Lucas_Werkmeister_WMDE, Jonas, daniel, Addshore, aude, Lydia_Pintscher, Aklapper, thiemowmde, Lahi, Gq86, GoranSMilovanovic, QZanden, HJiang-WMF, Agabi10, dpatrick, Luke081515, Wikidata-bugs, GWicke, Bawolff, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Jay8g, Legoktm, greg, mmodell___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff removed a project: Security.Herald added a project: Security. TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Cpaulf30, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, HJiang-WMF, Lewizho99, Maathavan, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff added a comment.
In T182800#3835104, @Lucas_Werkmeister_WMDE wrote:
Ah, but plaintext parameters are, like raw parameters, processed after the message is parsed, so {{PLURAL:$3|claim|claims}} no longer works :/
Oh, I didn't think about that. Just use a normal ->params() and wrap in wfEscapeWikiText() instead.TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Cpaulf30, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, HJiang-WMF, Lewizho99, Maathavan, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Jay8g, Legoktm___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T182800: Username beginning with asterisk renders as list in “restore”/“undo” edit summaries of Wikibase items
Bawolff added a comment.
In T182800#3834874, @Lucas_Werkmeister_WMDE wrote:
Possible fix:
diff --git a/lib/includes/Formatters/AutoCommentFormatter.php b/lib/includes/Formatters/AutoCommentFormatter.php
index 0c77d8762..b57ab5580 100644
--- a/lib/includes/Formatters/AutoCommentFormatter.php
+++ b/lib/includes/Formatters/AutoCommentFormatter.php
@@ -100,7 +100,7 @@ public function formatAutoComment( $auto ) {
}
// render the autocomment
- $auto = $msg->params( $args )->parse();
+ $auto = $msg->plaintextParams( $args )->parse();
return $auto;
}
But I have no idea if this breaks something else – it’s possible that some of the message parameters should be interpreted as Wikitext. (As far as I can tell, AutoCommentFormatter itself has no idea what the parameters mean – it just extracts the partial message key and the parameters from the edit summary and combines them. So it’s also possible that the escaping should happen before writing the username to the edit summary.)
@Bawolff if you think this is unlikely to be an XSS, perhaps you can make the task public and let the rest of the Wikidata team have a look? (I agree, FWIW, I just thought “better safe than sorry”.)
Made public.
Your proposed patch looks like it would fix the issue.TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, HJiang-WMF, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Jay8g, Legoktm___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T180892: Potential security vulnerability found in the rubocop and rubyzip dependencies
Bawolff closed this task as a duplicate of T180878: Upgrade rubocop across the extension fleet. TASK DETAILhttps://phabricator.wikimedia.org/T180892EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Niedzielski, Lahi, GoranSMilovanovic, QZanden, HJiang-WMF, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Bawolff, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T180892: Potential security vulnerability found in the rubocop and rubyzip dependencies
Bawolff added a project: Security. TASK DETAILhttps://phabricator.wikimedia.org/T180892EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Niedzielski, Lahi, GoranSMilovanovic, QZanden, HJiang-WMF, dpatrick, Luke081515, Wikidata-bugs, aude, GWicke, Bawolff, Stype_and_Co.-WMF, Jalexander, Parent5446, Anomie, Grunny, MaxSem, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T179010: re-enable Wikidata Recent Changes integration on Commons
Bawolff added a comment. Is there an estimate on the number of rows in a given time period this would be?TASK DETAILhttps://phabricator.wikimedia.org/T179010EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, Aklapper, daniel, jcrespo, thiemowmde, hoo, Lydia_Pintscher, Marostegui, Vali.matei, Minhnv-2809, Poyekhali, Volker_E, Wong128hk, Luke081515, Wikidata-bugs, GWicke, El_Grafo, Steinsplitter, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T177772: Purge 90% of rows from recentchanges (and posibly defragment) from commonswiki and ruwiki (the ones with source:wikidata)
Bawolff added a comment. Hi, There's been reports of high amounts of lag on commons causing read only mode, especially between 7:10-10:10 UTC today. (I filed T178094) Perhaps the rate of deletion of commons RC entries is too aggresive?TASK DETAILhttps://phabricator.wikimedia.org/T12EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jcrespo, BawolffCc: Stashbot, Jdforrester-WMF, Bawolff, Lydia_Pintscher, hoo, Ladsgroup, Base, Aklapper, TerraCodes, Jay8g, Liuxinyu970226, Marostegui, jcrespo, GoranSMilovanovic, Abiyoyo, QZanden, Jack_who_built_the_house, Minhnv-2809, Iniquity, Luke081515, Wikidata-bugs, aude, putnik, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis
Bawolff added a comment. Well wikidata is almost certainly a contributing factor, (particularly for russian) I would hesitate to blame it solely for slow ores on watchlist speeds, without more evidence. Especially on english wikipedia with its large recentchanges table and relatively low usage of wikidata. So addendum to this. For the enwiki case, and talking about watchlist (Not Special:RecentChanges) all the timeouts I could find - https://logstash.wikimedia.org/goto/3183d6a077082f6b4469255e51e60105 (This are just the severe read timeouts. I had trouble making a logstash query for the query longer than 5 seconds warning) had STRAIGHT_JOIN specified, including people with small watchlists. This probably makes sense for Special:Recentchanges case, but for the watchlist case, when the user has a small watchlist, this will cause the query to be much slower then needed. I'd reccomend removing the STRAIGHT_JOIN in the watchlist case for ORESTASK DETAILhttps://phabricator.wikimedia.org/T171027EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jcrespo, BawolffCc: Matthewrbowker, Noella94, Nirmos, Stryn, Mike_Peel, Capankajsmilyo, Elitre, Risker, Peachey88, Stashbot, Finavon, WMDE-leszek, saper, Masti, Lydia_Pintscher, D3r1ck01, matej_suchanek, Ankry, Ladsgroup, Lsanabria, Josve05a, Bawolff, greg, Dominicbm, Vriullop, Jmabel, Fae, IKhitron, Johan, Herzi.Pinki, jmatazzoni, Mattflaschen-WMF, KTC, Framawiki, zhuyifei1999, Marostegui, aaron, Andrei_Stroe, Turbojet, Rsocol, Strainu, Jwh, Pyb, Darwinius, Arbnos, Jdforrester-WMF, TheDJ, gerritbot, VladXe, Kf8, Liuxinyu970226, Jay8g, TerraCodes, Iniquity, jcrespo, Reedy, Catrope, Vicpeters, Demidenko, MaxBioHazard, Aklapper, Waytogoeducation, Lordiis, GoranSMilovanovic, Adik2382, Abiyoyo, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Vali.matei, Jack_who_built_the_house, Lewizho99, Minhnv-2809, Maathavan, Poyekhali, Volker_E, Wong128hk, Luke081515, Wikidata-bugs, Base, aude, GWicke, El_Grafo, Gryllida, putnik, Steinsplitter, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T177966: Add CORS-enabled, cacheable way to access contents of Data namespace
Bawolff added a comment. Correction: the response is cached according to the maxage specified in the request; however, I’m not sure if this works if pages are edited or purged (as far as I can tell, the browser doesn’t validate its cached data), so it can be hard to choose the right maxage. (This workaround also requires that you parse and transform the canonical URI, which is ugly.) This is also true for action="" action="" is not purged and only gets an (s)maxage if set by url parameter. (exception: ="" and ="" are purged, but other action="" urls are not. See Title::getCdnUrls).TASK DETAILhttps://phabricator.wikimedia.org/T177966EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, hoo, Ladsgroup, daniel, Aklapper, Jdforrester-WMF, Smalyshev, Lucas_Werkmeister_WMDE, Dfil7, Icedevil, GoranSMilovanovic, 45Jayjay1969, QZanden, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis
Bawolff added a comment. In T171027#3676023, @jmatazzoni wrote: In T171027#3673060, @Lydia_Pintscher wrote: This is a hugely political issue. Let's please not do this unless necessary. Right now, ORES is unusable on Watchlist for English, Russian and probably some other big wikis. It causes delays of 30 seconds to a minute when users have more than 3 days set. I'm told Wikidata is a likely culprit. If that's correct (I can't say it is or isn't), then by that standard, some kind of change appears to be "necessary," and, as Risker says, some kind of escalation appears both justified and required. Well wikidata is almost certainly a contributing factor, (particularly for russian) I would hesitate to blame it solely for slow ores on watchlist speeds, without more evidence. Especially on english wikipedia with its large recentchanges table and relatively low usage of wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T171027EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jcrespo, BawolffCc: Noella94, Nirmos, Stryn, Mike_Peel, Capankajsmilyo, Elitre, Risker, Peachey88, Stashbot, Finavon, WMDE-leszek, saper, Masti, Lydia_Pintscher, D3r1ck01, matej_suchanek, Ankry, Ladsgroup, Lsanabria, Josve05a, Bawolff, greg, Dominicbm, Vriullop, Jmabel, Fae, IKhitron, Johan, Herzi.Pinki, jmatazzoni, Mattflaschen-WMF, KTC, Framawiki, zhuyifei1999, Marostegui, aaron, Andrei_Stroe, Turbojet, Rsocol, Strainu, Jwh, Pyb, Darwinius, Arbnos, Jdforrester-WMF, TheDJ, gerritbot, VladXe, Kf8, Liuxinyu970226, Jay8g, TerraCodes, Iniquity, jcrespo, Reedy, Catrope, Vicpeters, Demidenko, MaxBioHazard, Aklapper, Waytogoeducation, Lordiis, GoranSMilovanovic, Adik2382, Abiyoyo, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Vali.matei, Jack_who_built_the_house, Lewizho99, Minhnv-2809, Maathavan, Poyekhali, Volker_E, Wong128hk, Luke081515, Wikidata-bugs, Base, aude, GWicke, El_Grafo, Gryllida, putnik, Steinsplitter, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T177707: don't dispatch changes to all affected pages for highly used items
Bawolff added a comment. In T177707#3673488, @Mike_Peel wrote: "Open question: Where should the cut-off initially be?" - the problem I have here is that it's particularly useful to see changes to highly-used pages, as it's those same pages that need to be watched closer to make sure that vandalism is quickly reverted. E.g. if a country name is vandalised, that needs to be caught quickly. If that's not feasible, then I'm not sure I see the benefit of having a middle-region, perhaps it should only appear for the directly linked page... Or maybe it should show in RelatedChanges rather than RecentChanges. RelatedChanges, RecentChanges, and watchlist are all the same behind the scenes. They all have the same feasibility concerns.TASK DETAILhttps://phabricator.wikimedia.org/T177707EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Mike_Peel, gerritbot, Jdforrester-WMF, brion, Mattflaschen-WMF, Strainu, TerraCodes, Jay8g, Liuxinyu970226, jcrespo, Bawolff, Aklapper, hoo, daniel, Ladsgroup, Lydia_Pintscher, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171027: "2062 Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis
Bawolff added a comment. In T171027#3667090, @jcrespo wrote: The introduction of wikidata events on recentchanges has converted the "light" recentchanges table into a monolithical 500GB table: commonswiki]> SHOW TABLE STATUS like 'recentchanges'\G *** 1. row *** Name: recentchanges Rows: 617078906 Avg_row_length: 566 Data_length: 349283375366 Index_length: 20766761170 Auto_increment: 965208270 This was a) Not discussed previously with us DBAs b) created huge performance issues c) Made maintenance impossible d) break recentchanges functionality for users e) break watchlist functionality for users f) after report of breakage almost 3 months ago, no workaround/mitigation as been done g) we are close of running out of space on several main database servers, breaking all of Wikipedia h) propose to create even newer indexes, which only makes all of the above problems worse. Given all of the above, I administratively will take the emergency decision (because "things are broken)" of finding out which functionality created this issue- revert it on code and purge all new rows created. Once that has been done, the owners of the functionality can requests it to be enabled again, after a strategy not breaking production is proposed. I am switching this to unbreak now to reflect how bad things are, and that I am taking leadership to get something finally done. I believe that the setting you are looking for is $wgWBClientSettings['injectRecentChanges']TASK DETAILhttps://phabricator.wikimedia.org/T171027EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jcrespo, BawolffCc: D3r1ck01, matej_suchanek, Ankry, Ladsgroup, Lsanabria, Josve05a, Bawolff, greg, Dominicbm, Vriullop, Jmabel, Fae, IKhitron, Johan, Herzi.Pinki, jmatazzoni, Trizek-WMF, Mattflaschen-WMF, KTC, Framawiki, zhuyifei1999, Marostegui, aaron, Andrei_Stroe, Turbojet, Rsocol, Strainu, Jwh, Pyb, Darwinius, Arbnos, Jdforrester-WMF, TheDJ, gerritbot, VladXe, Kf8, Liuxinyu970226, Jay8g, TerraCodes, Iniquity, jcrespo, Reedy, Catrope, Vicpeters, Demidenko, MaxBioHazard, Aklapper, Waytogoeducation, GoranSMilovanovic, Abiyoyo, QZanden, Vali.matei, Jack_who_built_the_house, Minhnv-2809, Poyekhali, Volker_E, Izno, Wong128hk, Luke081515, Wikidata-bugs, Base, aude, GWicke, El_Grafo, Gryllida, putnik, Steinsplitter, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171027: "2062 Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis
Bawolff added a comment. They're not fully redundant, since rc_type for Wikidata is RC_EXTERNAL (from core, thus not Wikidata-specific). Afaict only wikidata uses it. Flow uses a different number. Personally i think it would have made more sense to stick with numbers and have each ext pick a unique one, but that ship has sailed... The IN would at best be a range condition (although im not sure mariadb would see it that way because it cant tell its a contiguous range). Usually the range has to be the rightmost part of the index we're using, so i dont think that would work, as the idea is to segregate the table by putting the wikidata stuff by putting that at the leftmost part of the index. (It could maybe do index merge or we could manually UNION, but it seems like mariadb doesnt usually choose that path, and im not sure thats really ideal given how many rows the query already has to look at). I think perhaps an option here would be a virtual is wikidata column so it could be a binary condition and not a range, but itd have to be a wmf hack as mw min mysql version doesnt support virtual columns .TASK DETAILhttps://phabricator.wikimedia.org/T171027EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Ankry, Ladsgroup, Lsanabria, Josve05a, Bawolff, greg, Dominicbm, Vriullop, Jmabel, Fae, IKhitron, Johan, Herzi.Pinki, jmatazzoni, Trizek-WMF, Mattflaschen-WMF, KTC, Framawiki, zhuyifei1999, Marostegui, aaron, Andrei_Stroe, Turbojet, Rsocol, Strainu, Jwh, Pyb, Darwinius, Arbnos, Jdforrester-WMF, TheDJ, gerritbot, VladXe, Kf8, Liuxinyu970226, Jay8g, TerraCodes, Iniquity, jcrespo, Reedy, Catrope, Vicpeters, Demidenko, MaxBioHazard, Aklapper, Waytogoeducation, GoranSMilovanovic, Abiyoyo, QZanden, Vali.matei, Jack_who_built_the_house, Minhnv-2809, Poyekhali, Volker_E, Izno, Wong128hk, Luke081515, Wikidata-bugs, Base, aude, GWicke, El_Grafo, Gryllida, putnik, Steinsplitter, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T172914: mw.wikibase.entity: Use __index to lazy register entity usages
Bawolff added a comment.
As an aside, in the case of commons, it might make sense to always record label usage as being for all languages, instead of which specific language, since commons uses weird {{int:...}} hacks for multilingualness, which won't record all the usages for non-canonical language parses (OTOH, that's an issue commons has had with recording link usages for a very long time, so its not like non-canonical parse link tracking issues is anything new to commons)TASK DETAILhttps://phabricator.wikimedia.org/T172914EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: eranroz, BawolffCc: Bawolff, thiemowmde, gerritbot, Halfak, Aklapper, daniel, Lydia_Pintscher, aude, Liuxinyu970226, CennoxX, Scott_WUaS, Ltrlg, Oliv0, Izno, eranroz, PokestarFan, Doc_James, hoo, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T151717: Usage tracking: record which statement group is used
Bawolff added a comment. I suspect that having more rows in recentchanges is much much worse than having more rows in wbc_entity_usage.TASK DETAILhttps://phabricator.wikimedia.org/T151717EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, eranroz, Ottomata, PokestarFan, Ladsgroup, Stashbot, gerritbot, Halfak, jcrespo, TomT0m, Hall1467, hoo, zhuyifei1999, Eloquence, Lydia_Pintscher, Sannita, Ainali, Liuxinyu970226, MZMcBride, Ricordisamoa, Micru, jayvdb, Daniel_Mietchen, Tobi_WMDE_SW, Legoktm, Abraham, Wikidata-bugs, liangent, jeremyb, aude, Bianjiang, Aklapper, DixonD, daniel, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Marostegui, Lewizho99, Minhnv-2809, Maathavan, Izno, Luke081515, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T151717: Usage tracking: record which statement group is used
Bawolff added a comment. In T151717#3598222, @Halfak wrote: I think the idea is that we'll be able to include wbc_entity_usage to increase granularity in watchlists once this is solved for. It will require some new work though :) Happy to see @Bawolff excited about this functionality. My understanding is that when someone makes an edit on wikidata, the edit goes into all the recentchanges tables based on if the page is used according to wbc_entity_usage. Due to lack of granuality in wbc_entity_usage, this has caused a spike in the size of the recentchanges table (For example, on romanian wiki, in a 1 week period 98.93% of entries in the recentchanges table were wikidata related (roughly 7000 normal edits vs 1 million wikidata edits). I believe this is overloading the watchlist functionality. My hope is that by using fine grained tracking on wbc_entity_usage, only when someone edits the actual property in use, will a wikidata edit be propogated to the local recentchanges table, which would significantly reduce the size of that table.TASK DETAILhttps://phabricator.wikimedia.org/T151717EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, eranroz, Ottomata, PokestarFan, Ladsgroup, Stashbot, gerritbot, Halfak, jcrespo, TomT0m, Hall1467, hoo, zhuyifei1999, Eloquence, Lydia_Pintscher, Sannita, Ainali, Liuxinyu970226, MZMcBride, Ricordisamoa, Micru, jayvdb, Daniel_Mietchen, Tobi_WMDE_SW, Legoktm, Abraham, Wikidata-bugs, liangent, jeremyb, aude, Bianjiang, Aklapper, DixonD, daniel, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Marostegui, Lewizho99, Minhnv-2809, Maathavan, Izno, Luke081515, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T151717: Usage tracking: record which statement group is used
Bawolff added a comment. I suspect that fixing this bug will significantly help with T171027 (watchlists being too slow)TASK DETAILhttps://phabricator.wikimedia.org/T151717EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, eranroz, Ottomata, PokestarFan, Ladsgroup, Stashbot, gerritbot, Halfak, jcrespo, TomT0m, Hall1467, hoo, zhuyifei1999, Eloquence, Lydia_Pintscher, Sannita, Ainali, Liuxinyu970226, MZMcBride, Ricordisamoa, Micru, jayvdb, Daniel_Mietchen, Tobi_WMDE_SW, Legoktm, Abraham, Wikidata-bugs, liangent, jeremyb, aude, Bianjiang, Aklapper, DixonD, daniel, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Marostegui, Lewizho99, Minhnv-2809, Maathavan, Izno, Luke081515, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171274: Security review of wikiba.se
Bawolff added a comment. To answer my own question: https://github.com/wikimedia/wikiba.seTASK DETAILhttps://phabricator.wikimedia.org/T171274EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, PokestarFan, Aklapper, JanZerebecki, hoo, thiemowmde, JeroenDeDauw, Jonas, Addshore, Ivanhercaz, Ladsgroup, faidon, GoranSMilovanovic, QZanden, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171274: Security review of wikiba.se
Bawolff added a comment.Herald added a subscriber: PokestarFan. Is the site in a git repo somewhere?TASK DETAILhttps://phabricator.wikimedia.org/T171274EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, PokestarFan, Aklapper, JanZerebecki, hoo, thiemowmde, JeroenDeDauw, Jonas, Addshore, Ivanhercaz, Ladsgroup, faidon, GoranSMilovanovic, QZanden, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T170927: Make wbqc_constraints table available on Quarry et al.
Bawolff added a comment. I approve on behalf of #security-teamTASK DETAILhttps://phabricator.wikimedia.org/T170927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Reedy, Bawolff, dpatrick, PokestarFan, chasemp, bd808, gerritbot, Marostegui, Lucas_Werkmeister_WMDE, Aklapper, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tbscho, Kaartic, Lewizho99, Minhnv-2809, Maathavan, ZhouZ, Izno, Luke081515, Mpaulson, Wikidata-bugs, aude, Gryllida, jayvdb, Slaporte, scfc, csteipp, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T159708: Deploy WikibaseMediaInfo extension to production
Bawolff closed subtask T159709: Security review for WikibaseMediaInfo extension as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T159708EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Ricordisamoa, Aklapper, Lydia_Pintscher, QZanden, Acer, Urbanecm, Izno, Luke081515, Wikidata-bugs, Base, matthiasmullie, aude, Deskana, Fabrice_Florin, Mbch331, Jay8g, Krenair, Tgr___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T159709: Security review for WikibaseMediaInfo extension
Bawolff moved this task from Scheduled to Done on the Security-Reviews board.Bawolff closed this task as "Resolved".Bawolff claimed this task.Bawolff added a comment. Sorry for the delay in reviewing this one. Security review passed. There's not much to say. Most of the interface work is done by Wikibase, so there's not very much attack surface in this extension. Two minor comments unrelated to security that I have: It doesn't matter, but it is kind of odd there is a special page alias file when there's no special pages. The discussion tab on a MediaInfo page leads the the media info id number in the main namespace. This seems wrong. I would expect either there be no discussion tab in the media info view, or the media info namespace be similar to the annotations extension where it appears as if its attached to the file namespace and the talk tab goes back to the File_talk namespace. TASK DETAILhttps://phabricator.wikimedia.org/T159709WORKBOARDhttps://phabricator.wikimedia.org/project/board/944/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, dpatrick, Ricordisamoa, Aklapper, Lydia_Pintscher, QZanden, Acer, Izno, Luke081515, Wikidata-bugs, Base, matthiasmullie, aude, Deskana, JanZerebecki, Fabrice_Florin, csteipp, Mbch331, Jay8g, Legoktm, Tgr___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T159697: Special:NewItem - Create a new item button isn't showing thumbnails on Wikidata
Bawolff changed the title from "[Bug] Special: Create a new item button isn't showing thumbnails on Wikidata" to "Special:NewItem - Create a new item button isn't showing thumbnails on Wikidata". TASK DETAILhttps://phabricator.wikimedia.org/T159697EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Viveksr96, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T159697: [Bug] Special: Create a new item button isn't showing thumbnails on Wikidata
Bawolff added a project: Wikidata. TASK DETAILhttps://phabricator.wikimedia.org/T159697EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Viveksr96, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T156240: Stop writes on hash conflicts & log that they occour
Bawolff added a comment. In T156240#2971262, @daniel wrote: @Bawolff well, right now, all the vandal has to do is go to the page and add [[nds:Bawolff sucks...GHHDCBTSfgjbftgdthn"]] to the page... Granted, the fix is a bit less obvious, but deleting a page is easy enough. I agree its somewhat of a far fetched scenario (since its high effort for a relatively low amount of disruption). As I said in the parent task, im not sure how important this should be. Maybe we should just document it and deem it an acceptable risk. However the more I think about it the more I like the idea of mitigating by using a keyed hmac with a secret key (to prevent offline attacks)TASK DETAILhttps://phabricator.wikimedia.org/T156240EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, BawolffCc: Bawolff, Lydia_Pintscher, Aklapper, daniel, gerritbot, Addshore, D3r1ck01, Andrew-WMDE, Izno, Wikidata-bugs, aude, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T156240: Stop writes on hash conflicts & log that they occour
Bawolff added a comment. The scenario i was thinking of is someone uses gpus to brute force a conflict between a real title and the normalized version of a naughty string. So e.g. if "Dog" and "Bawolff sucks...GHHDCBTSfgjbftgdthn" collide after normalization (this is just a theoretical example, they dont actually collide), the vandal could create the page "Bawolff sucks...GHHDCBTSfgjbftgdthn" on an obscure language and now suddenly the en page for Dog has an interlanguage link to a maliciously titled page, and the users dont understand what happened.TASK DETAILhttps://phabricator.wikimedia.org/T156240EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, BawolffCc: Bawolff, Lydia_Pintscher, Aklapper, daniel, gerritbot, Addshore, D3r1ck01, Andrew-WMDE, Izno, Wikidata-bugs, aude, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T149082: Security review for Cognate Extension
Bawolff added a comment. In T149082#2968137, @Addshore wrote: In T149082#2966632, @Bawolff wrote: I assume this is not using the LinkUpdates related hooks because it only wants to deal with new pages not edits (?) However it seems that this still triggers on all edits. Perhaps it should look at the EDIT_NEW flag in the onPageSaveComplete hook to avoid some unnecessary database interaction. Cognate needs to know when pages are edited to determine if the redirect state has changed: redirect -> regular page = needs to be added to the db regular page -> redirect = needs to be removed from the db If I had both the new and the last content then I would be able to check the redirect state of each and only act where needed here. I'll have a further look. Oh. This makes sense to me now. When i was first looking at it I didnt realize it needed to do thatTASK DETAILhttps://phabricator.wikimedia.org/T149082EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, daniel, Aklapper, Addshore, Lydia_Pintscher, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Andrew-WMDE, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T149082: Security review for Cognate Extension
Bawolff moved this task from Scheduled to Done on the Security-Reviews board.Bawolff added a comment. Security review of Cognate extension (As of a187d934b8c6) Normal issues Use sha256 (or some other modern hash) instead of md5. Even in contexts where the attacks against it is not important we should be phasing out md5. Issues of unclear severity 64-bits is not enough for collision resistance against a malicious adversary. If I have my math right (It is very possible that I mixed this up) There are 5 million (~2^22) titles on enwiktionary. 2^64/2^22 = 2^42. Based on googling, a 4 GPU system can do roughly 2^33 hashes/second. 2^42/2^33 = 2^11 seconds ~ half an hour to find a collision. So a vandal could make malicious page titles that collide with titles on enwiktionary, for the purpose of vandalism via the lang links. I'm not sure how serious an issue this is. Its clearly a lot more work for less disruption than most forms of vandalism, but it could be confusing to users who wouldn't understand what's going on. I think it may be an acceptable risk, but users should be consulted about the possibility before the extension is enabled. The risk should also be documented. Alternatively the risk could be prevented by using autoincrement ids (would require storing both the normalized and raw title though) or by increasing the size of the hash to 128 bits (e.g. Having two BIG INT fields and joining on both) Minor issues line 68 of populateCognatePages.php Its preferred to use the MW DB abstraction layer instead of hand constructing sql where possible (instead of "page_namespace IN " . ..., do "page_namespace" => $namespaces). Non-security issues CacheUpdateJob doesn't update page_touched. More generally shouldn't this use built-in HTMLCacheUpdateJob for forward compatibility with any future changes to how caching works in MediaWiki? Also this would allow core's deduplication code to be used. At one point I thought that this would be unnecessary, since the language links from this extension are generated on every (non-varnish cached) view (as opposed to stored in parser cache). However it actually is necessary since MW will give 304 not modified responses based on page_touched. This assumes that all sites have same interwiki structure for language links or things will break. This is fine since its true on wiktionary, however I think this requirement should be clearly documented. The indexe on cognatePages for the queries from selectLinkDetailsForPage, selectSitesForPage seem to be not quite right. I think the index should be (cpga_title, cpga_namespace, cpga_sites). I assume this is not using the LinkUpdates related hooks because it only wants to deal with new pages not edits (?) However it seems that this still triggers on all edits. Perhaps it should look at the EDIT_NEW flag in the onPageSaveComplete hook to avoid some unnecessary database interaction. TASK DETAILhttps://phabricator.wikimedia.org/T149082WORKBOARDhttps://phabricator.wikimedia.org/project/board/944/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, daniel, Aklapper, Addshore, Lydia_Pintscher, D3r1ck01, Andrew-WMDE, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T149083: Security review for InterwikiSorting Extension
Bawolff moved this task from Scheduled to Done on the Security-Reviews board.Bawolff closed this task as "Resolved".Bawolff claimed this task.Bawolff added a comment. Security review of InterwikiSorting revision 7d48e09104136 (Jan 3, 2017) Extension looks good. One small (non-security) comment: In InterwikiSorter.php code comment references a doc file which doesn't seem to exist: @see Documentation of "sort" and "interwikiSortOrders" options in docs/options.wiki. TASK DETAILhttps://phabricator.wikimedia.org/T149083WORKBOARDhttps://phabricator.wikimedia.org/project/board/944/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, Reedy, aude, Legoktm, Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, Andrew-WMDE, dpatrick, Izno, Luke081515, Wikidata-bugs, JanZerebecki, csteipp, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T150183: Deploy InterwikiSorting extension to production
Bawolff closed subtask T149083: Security review for InterwikiSorting Extension as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T150183EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Ladsgroup, Aklapper, Addshore, Lydia_Pintscher, Th3d3v1ls, Zppix, Urbanecm, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, faidon, Mbch331, Jay8g, Krenair, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T135961: ParserTest_LuaCommon__luaParserTests::testParserTest fails on master
Bawolff added a comment. In https://phabricator.wikimedia.org/T135961#2316963, @Bawolff wrote: > Umm, I thought I had already fixed this. Or I guess that would be //you// already fixed it ;) TASK DETAIL https://phabricator.wikimedia.org/T135961 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Anomie, Bawolff Cc: Bawolff, Aklapper, Zppix, demon, Legoktm, JanZerebecki, hoo, D3r1ck01, Izno, Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, fbstj, Anomie, AuFCL, Jackmcbarn, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T135961: ParserTest_LuaCommon__luaParserTests::testParserTest fails on master
Bawolff added a comment. I guess - F3939586: T110143-scribunto-REL1_23b.patch <https://phabricator.wikimedia.org/F3939586> - F3939587: T110143-scribunto-master_b.patch <https://phabricator.wikimedia.org/F3939587> - F3939588: T110143-scribunto-REL1_25b.patch <https://phabricator.wikimedia.org/F3939588> never got applied TASK DETAIL https://phabricator.wikimedia.org/T135961 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Anomie, Bawolff Cc: Bawolff, Aklapper, Zppix, demon, Legoktm, JanZerebecki, hoo, D3r1ck01, Izno, Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, fbstj, Anomie, AuFCL, Jackmcbarn, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T135961: ParserTest_LuaCommon__luaParserTests::testParserTest fails on master
Bawolff added a comment. Umm, I thought I had already fixed this. TASK DETAIL https://phabricator.wikimedia.org/T135961 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Anomie, Bawolff Cc: Bawolff, Aklapper, Zppix, demon, Legoktm, JanZerebecki, hoo, D3r1ck01, Izno, Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, fbstj, Anomie, AuFCL, Jackmcbarn, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T120452: Allow tabular datasets on Commons (or some similar central repository) (CSV, TSV, JSON, XML)
Bawolff added a comment. > I think there's a very valuable use-case in data sets well below the 100mb range That was just a general example, because it wasn't clear to me if this was being sold as a general purpose solution for all data-sets. 4 mb is the actual limit for wikipages, and honestly, things get kind of sucky once you go > 1 mb. As an aside, I'd note that if we're making up our own custom data formats, Lua already has a load data thing for loading data sets formatted as lua tables. TASK DETAIL https://phabricator.wikimedia.org/T120452 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Milimetric, Bawolff Cc: Bawolff, MZMcBride, Alkamid, Milimetric, Thryduulf, JEumerus, MarkTraceur, Yurik, Matanya, ekkis, matmarex, Lydia_Pintscher, Aklapper, Steinsplitter, StudiesWorld, DannyH, D3r1ck01, Izno, Wikidata-bugs, aude, El_Grafo, Ricordisamoa, Fabrice_Florin, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T120452: Allow tabular datasets on Commons (or some similar central repository) (CSV, TSV, JSON, XML)
Bawolff added a comment. > We already have pretty robust support for pages containing text. Not if your data-set is 100 mb big. I think this bug maybe needs some scope clarification before deciding which approach is best. > I think the best way forward is to post on commons proposing to add a new namespace there. This might not be the easiest sell to the commons community. Well its possible they might like the idea, I would recommend thinking hard about how this might impact them, in order to have good answers to questions they might ask (e.g. Things that would likely come up are how are datasets attributed, and are the patrolling/anti-vandalism tools sufficient to deal with this type of content) TASK DETAIL https://phabricator.wikimedia.org/T120452 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Milimetric, Bawolff Cc: Bawolff, MZMcBride, Alkamid, Milimetric, Thryduulf, JEumerus, MarkTraceur, Yurik, Matanya, ekkis, matmarex, Lydia_Pintscher, Aklapper, Steinsplitter, StudiesWorld, DannyH, D3r1ck01, Izno, Wikidata-bugs, aude, El_Grafo, Ricordisamoa, Fabrice_Florin, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T110012: Date format in file infobox on commons localized incorectly in Chechen (ce)
Bawolff added a project: Wikidata.org. Herald added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T110012 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: siebrand, Rillke, Bawolff, Steinsplitter, Umar, Wikidata-bugs, aude, El_Grafo, Gryllida, Shizhao, Arrbee, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T110012: Date format in file infobox on commons and at wikidata localized incorectly in Chechen (ce)
Bawolff changed the title from Date format in file infobox on commons localized incorectly in Chechen (ce) to Date format in file infobox on commons and at wikidata localized incorectly in Chechen (ce). TASK DETAIL https://phabricator.wikimedia.org/T110012 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: siebrand, Rillke, Bawolff, Steinsplitter, Umar, Wikidata-bugs, aude, El_Grafo, Gryllida, Shizhao, Arrbee, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
