Jul 20 2021
Jul 19 2021
Did I actually need to request a new consumer? It’s now been pointed out to me that there is a checkbox to “Reset the secret key to a new value” in the page to update the consumer – would that have been enough?
Jul 18 2021
Works now, thanks a lot!
Jul 17 2021
Ohhhh. That’s true, I completely forgot about the logs.
Most of the volume mounts are already read-only:
Jul 15 2021
But as an approximation, I’ve pushed a pygments-server change to override the Python open() function before calling Pygments. It may break if Pygments changes how it reads files, but for now it works as another defense layer (I’ve tested it locally).
The whole point of my pygments-server, as opposed to the other one, is that it doesn’t parse the command line, because that limits the ways in which it can be used. I don’t control Extension:SyntaxHighlight, I don’t know which parts of pygments’ CLI it’ll start to use tomorrow.
Isn’t it redundant with $wgServer or one of the related variables?
Alright, I added this to the LocalSettings.php:
I think this is fixed; no secrets were revealed in this task, so I think it can be made public too.
Alright, after a false start where I accidentally took down the wiki by blocking ingress to all pods, including the webservice, I think it’s working now.
I thought a generally accessible pygments-server might potentially be useful, but now I don’t feel confident enough anymore that k8s isn’t mounting random stuff elsewhere in the container. Let’s see if I can figure out network policies.
Ugh, you’re right.
The fix here is to use Kubernetes network policies to limit incoming traffic to the pygments server service.
Jul 14 2021
Also, note how the edit links in the sitelink groups (first screenshot) still say edit, rather than “golygu” as in ?uselang=cy.
Possible blocker: T286679: Some interface messages are in Welsh when British English is selected as the interface language isn’t a very serious issue, but may annoy a number of English Wikipedia users if it reaches group2. (It’s not yet clear how many messages would be affected, and I also don’t know how many people actually have their user interface set to en-gb.)
At least the footer seems to affect Wikipedias as well – https://ca.wikipedia.org/wiki/Portada?uselang=en-gb has the following footer on my end:
https://www.wikidata.org/wiki/MediaWiki:Wikibase-sitelinks-wikiquote/en-gb shows the Welsh message text for some reason (which is at least consistent with it being shown on item pages).
On the other hand, the sidebar, for instance, is unaffected (in ?uselang=cy it’s different):
Jul 12 2021
For the record, I identified the problem early in the development of the framework. It was a conscious decision to leave it out in the first iteration because I wanted to collect clear use cases and expectations.
I was hoping that the wrapper approach that is suggested in wikitech was enough to cover basically all cases.
Jul 11 2021
In the slightly longer term, the ISA developers should probably request and configure a new OAuth consumer, and the old one should be disabled, since any Toolforge user could have stolen its secret in the past two years or so.
Alright, the old OAuth consumers are gone. I think we can close this. Thanks @bd808!
Alright, @bd808 approved the new consumer and I restarted the tool – seems to work as far as I can tell. (Task remains open since the old consumers are still enabled.)
New OAuth consumer has been requested and configured; I’ll restart the tool (to pick up the new configuration file) once it’s been approved.
Tentatively classifying as Vuln-Infoleak, though I’m not certain about that.
Jul 7 2021
Jul 6 2021
You can get some attribution information from the query+imageinfo+extmetadata API, if you want to (example code), but it’s probably easier to just make the image a link to Commons.
Jul 3 2021
I think just splitting on spaces would do more harm than good. A shell would probably be a viable option.
Jul 2 2021
- It looks like it’s not possible to pass arguments to the command being executed; I assume we’re expected to put any nontrivial commands into a shell script and use the shell script as the command?
You can add it in quotes, like --command "./my-command.py foo bar".
Thanks for the fingerprint.
I think the How It Ever Worked is that /etc/bash_completion.d/ isn’t loaded on-demand (which I guess is why it’s the legacy location and deprecated, because immediately loading all the completions takes a while)?
After typing misctools and then pressing Tab, become autocompletes correctly. If I understand correctly, completions in /usr/share/bash-completion/ are only loaded on-demand, so combining multiple completions into a single misctools file is not correct – they should be in files called become and sql, respectively, so that they’ll be autoloaded when trying to run autocompletion for those commands.
On the regular bastion, that completion comes from /etc/bash_completion.d/misctools, from the misctools package:
Looks like it’s not installed:
Jul 1 2021
I’d love to use the new jobs framework for Wikidata Shape Expressions Inference, which currently runs as a Grid webservice so that it can schedule Grid jobs.
Jun 29 2021
Hm, I didn’t consider new page creations, that’s a good point. I’ll check if there are any other reasons why Wikibase still has a separate API module.
Jun 28 2021
You can still get the error by adding ¬wikilambda-clear-preauth=false to the login URL (example).
Jun 26 2021
Confirmed, looks like this. (“Add a statement” finds no results because it’s searching for properties for other statements, not items as the “depicts” value, but I also fell for this before realizing that there must be an input field missing.)
Jun 24 2021
Jun 22 2021
Jun 19 2021
Jun 15 2021
Jun 14 2021
Jun 12 2021
I guess I’ll close this task now, the “cyclic” brokenness seems to be resolved.
Okay, Z5 is now fixed as well (I added a line zobject.Z2K1 = 'Z5'; before saving the edit). I guess that ID was just a mistake in the initial data (which was then fixed in Iee44178630).
Alright, fixing Z5 doesn’t work, because apparently the content of that page specifies the ID (Z2K1) as Z4 rather than Z5, which wikilamdba_edit then (rightfully, I suppose) complains about when trying to save the fixed revision.
Jun 7 2021
Big caveat: only counts namespace 0. Ideally it should probably respect $wgNamespacesToBeSearchedDefault.
Also, this doesn’t take $wgNamespacesToBeSearchedDefault into account.
Created using P16317 (sorted using sort, not part of the script).
Workaround using CirrusSearch elasticsearch replicas:
Jun 6 2021
It turns out that the “broken” objects can be fixed by converting their labels to the ZID form – see the history of https://notwikilambda.toolforge.org/w/index.php?title=ZObject:Z10001&action=history for an example.