In T437970#12409656, @Bugreporter wrote:

The issue is not access to repos/lua (though I expect every users should be able to create repos there). The issue is because abusing by spammers, all new users in GitLab are by default blocked unless unblocked manually or automatically by a bot. Being blocked means they have no access to GitLab at all.

In T418047#12414427, @Aplucas0703 wrote:

If the code had previously existed for it, was there a reason why it was removed? Did it break something or was it just an oversight (or even just an ill-sighted shortcut)?

A WebView can't enter full screen mode unless the host overrides WebChromeClient.onShowCustomView. That's why the full screen button is greyed out: the app doesn't do that. So it was probably always like this, not just since 2020.

The app has

transformer.register( "anchorPopUpMediaTransforms", function( content ) {
    // look for video thumbnail containers (divs that have class "PopUpMediaTransform"),
    // and enclose them in an anchor that will lead to the correct click handler...
    var mediaDivs = content.querySelectorAll( 'div.PopUpMediaTransform' );

In T437970#12409414, @Bugreporter wrote:

The strong issue existing is we need to be an admin to deploy packages.

In T418047#12291973, @Aplucas0703 wrote:

It should be noted that the video player issues are actually a very big deal for legal and ethical reasons and should to be upgraded in priority. There is currently no way to find the file information for any video from the Android app, either, because the video player provides no link to it. This is a violation of the Creative Commons license because the authors are not being provided attribution for their work, and is therefore a literal copyright violation. Fixing that has to be a priority.

Produnto has been deployed to the pilot wikis for two weeks and has had literally no usage in that time. If there continues to be no community interest in this extension, we can just undeploy it and cancel the project.

I don't see that as a problem.

Reducing priority -- nobody cared enough to submit this to the new wishlist.

In T421436#12361313, @STei-WMF wrote:

Thank you, can I get one line on what the benefit of this deployment is for users?

In T421436#12334889, @STei-WMF wrote:

@tstarling can you provide a draft please?

Tar library evaluation.

Sergio asked me to look at this.

It's not resolved, we reverted the fix for this.

I filed an issue and a PR https://github.com/debuerreotype/debuerreotype/issues/201

The next step is to deploy it to all wikis, but that wasn't asked for in the task description, that's why I resolved the task.

All done, I think.

In T437829#12317118, @MoritzMuehlenhoff wrote:

Looking at https://github.com/debuerreotype/debuerreotype/issues/75#issuecomment-557637414 using the (a little confusingly named) --non-debian option might already do what we need: https://gerrit.wikimedia.org/r/c/operations/puppet/+/1341110

I think it's mostly a bug in debuerreotype. The purpose of using snapshot.debian.org is for reproducible builds. The build isn't reproducible after the snapshot expires unless you configure apt to ignore Valid-Until. It doesn't seem to be intentional. I'm happy to file it upstream.

Base image build gave warnings:

The base image is broken. Locally I can do

Full terminal output: P96435

Use PostgreSQL (Chinese language, GBK encoding)

In T430644#12270089, @stjn wrote:

Is the idea then that code written in Produnto would not use any MW-specific variables or have access to basic MW-specific conveniences?

Requiring a Package: prefix in mw.loadJsonData() makes sense, there's no reason to not do that.

In T436202#12269556, @Samwilson wrote:

It looks like thumbs are now not working for PDFs, e.g. Special:UploadStash/thumb/1cwoifzo1wtc.2jnpbx.2.pdf/page1-120px-1cwoifzo1wtc.2jnpbx.2.pdf.jpg because the filename doesn't end in the stash name (it has .jpg appended).

In T420833#12254869, @Hakimi97 wrote:

@tstarling Since it was decided that the current solution is to block all public internet traffic except for those within the IP whitelist, should this task be boldly "resolved"?

In T420833#12245119, @AlexisJazz wrote:

I test gadgets, scripts, template changes and other things on beta to avoid disrupting production. When something strange happens on production, I try to reproduce it on beta cluster for the same reason. I have filed many bug reports based on testing on beta.

In T420833#12244804, @AlexisJazz wrote:

And what happened to "Every existing automation against Beta cluster would fail"?

I deployed Produnto to beta, but for the last 24 hours it's been too slow to verify whether it's working or not. I suggest switching to an allowlist of IP networks, allowing only WMF. No need to add staff IPs, we can use ssh -D. Volunteers can use ssh -D via Toolforge.

My upstream PR was accepted. License files are now available in the upstream git repo.

I previously did some analysis of runAllJobs races at T401044.

Logstash only has FileOperations logs at the WARNING and ERROR level, but we have DEBUG level logs on mwlog1003.

Lua 5.4 review notes:

When you go from zlib level 6 to level 9, the maximum chain length increases by a factor of 32. I think it would be possible to attack the hash function it uses to get quadratic performance in the chain length, for a worst case slowdown of 1024x. Still it would be hard to turn that into a DoS if that only takes it from microseconds to milliseconds. There are easier hashtables to attack. But it's something to keep in mind if you want to switch to a library which scales all the parameters far beyond that without seeding the hash functions. Even for non-malicious input, this zlib benchmark shows a strong dependence on the input data: a 5x slowdown for "html" and 33x for "pngpixels" when going from gzip -5 to gzip -9.

In T326773#12196367, @Ladsgroup wrote:

27% is honestly quite a lot. Is there a way I can push this forward? For example, putting it in tech news and see what people think.

I rewrote the task description since I am not a fan of that kind of AI slop.

Impact: This breaks core Lua table API consistency contracts. It silently neutralizes validation logic in custom frameworks and downstream code interacting with Module:Arguments, which relies entirely on indexed-lookups via __index to preserve lazy expansion.

There are version differences.

An infinite loop in Lua userspace is not a security issue.

Regarding the complaint that "SandboxDeleteHandler is missing a CSRF token checking whereas similar areas of code check for it", see Cross-site request forgery § HTTP verbs and CSRF. The DELETE method does not need a CSRF token, because browsers do not permit cross-origin DELETE requests, unless the origin opts in to it, which it doesn't. POST requests need to be protected against CSRF because cross-origin HTML form posting is allowed.

In T431845#12148826, @Osnard wrote:

Bumping dozens or hundreds of versions in extension.json needs automation. And such cases also don't need code review. We didn't want to cause problems and will adapt our tooling. This will take some time though. I guess the way the "libraryupdater" tool does it is the way to go then?

In T384167#11846735, @HakanIST wrote:

Would it make sense to use Blob.stream() on the client side to split the XML at <page> boundaries and POST each chunk to action=import separately? That way each request stays small with its own transaction, timeouts are avoided, and progress can be tracked in IndexedDB for resumability. The legacy no-JS form could get a size/revision cap as a fallback.

• "version squatting" fixed in 1319566 and 1319569
  • Not adding secret token authentication to the web hook as explained in the commit message
• URL protocol validation fixed in 1319573
• Language property validation fixed in 1319643
• LocalFileCollection path traversal fixed in 1319746

Per my comment upstream, it's a one-line fix in Swagger's .releaserc. The license files are generated by npm run build, but semantic-release-bot doesn't add them to git, due to a configuration error.

LuaSandbox manual PR: https://github.com/php/doc-en/pull/5725