Dear Maintainer,

resources/lib/
(https://sources.debian.org/src/mediawiki/1:1.39.4-2/resources/lib/)

include a few library already packaged for debian.

Moreover some source are missing (I have only checked pako).

You could use the packaged library under debian

Bastien

Hi,

These are in the preferred form for modification so I don't think
there's any issue here, but please correct me if I'm wrong. MediaWiki
often patches these libraries (e.g. jquery.ui) in this format hence IMO
meeting the "preferred form of the work for making modifications to it"
requirement of the GPL.

Older versions of the package did that, but the version mismatches were
not worth it. Plus MediaWiki has a ton of user-written code that's
stored and loaded on-wiki, so deviations from the official version are
incredibly hard to test and just cause breakage everywhere.

hi,
Le lun. 31 juil. 2023 à 08:27, Kunal Mehta <legoktm@debian.org> a écrit :

No https://sources.debian.org/src/mediawiki/1%3A1.39.4-2/resources/lib/pako/
is webpacked in order to be transformed in es5.... No source available
before webpack
so on could be packaged.

Moreover in all the case you should document the embed code in security tracker.

And do not stick to lastest jquery is a security problem. Are you sure
you have closed all the CVE ?

with my javascript hat, I believe that working with upstream to
improve the testing (using if needed selenium) will improve the
security of mediawiki by using packaged and up to date js

This bug should be solved package by package:
- first by doing an analysis of stable/not stable api => stable api use packaged
- for non stable and patched version => guarantee that source is here
- for non stable and patched version try to create test case with
upstream using selenium checking integration
- move to packaged

In all the case it decrease the burden from a security point of view

bastien

severity 1042532 normal
tags 1042532 wontfix
thanks

Hi,
pako's MIT license (aka Expat) and MediaWiki's GPL v2 or later license.
The pako_deflate.es5.js file contains the MIT license
information/attribution, so we're in compliance for that.

MediaWiki's GPL v2 requires source code to be in "preferred form of the
work for making modifications to it". In the context of MediaWiki, this
is in the preferred form, since that's how we plan to (and do) modify
it. If you want to patch MediaWiki, having the pre-transpiled sources is
going to be way more work than the source we're providing right now. And
the proof is that (AFAIK) MediaWiki devs will just patch these sources
directly, they don't go to the upstream sources, adjust those, and then
generate a patch. So I don't see a DFSG issue.

The ones that affect MediaWiki, I believe so. Upstream MediaWiki has at
least one or two jQuery team members as core developers who follow that
not to mention the Wikimedia Foundation's security team.

There is already upstream selenium-based testing, but using the latest
version of everything isn't always a feature.

No, it really doesn't, it just shifts it elsewhere. The more deviations
Debian makes, the less we can rely on upstream's QA processes for
ensuring we're shipping working software, which will more likely slow
down security updates. Since bundling is permitted by policy, we plan to
continue doing it.

Le lun. 14 août 2023 à 08:57, Kunal Mehta <legoktm@debian.org> a écrit :


Ni hère this is a dfsg problem. You do not recompile from source

So serious bug