Package: libnginx-mod-http-subs-filter
Version: 1.14.2-2+deb10u1
Severity: normal
When a page is sent with a Content-Encoding header, mod-http-subs-filter
as packaged by Debian does not process the content, even if the encoding
provided is 'identity' (the use of no transformations whatsoever).
Th
On 23/03/13 22:37, Filipus Klutiero wrote:
> Package: mediawiki
> Version: 1:1.19.4-1
> Severity: normal
>
> According to README.Debian:
>
>> The configuration uses an easy web-based system ; just go to this URL :
>> http://www.myserver.org/mediawiki/config/index.php
>> (replace b
On 04/03/13 23:37, Jonathan Wiltshire wrote:
> The problem is apparently introduced in r83855 and at this stage, I do not
> believe it affects stable, though I would not be confident enough to be sure
> yet.
Stable is based on 1.15.5, branched on r48811
It "only" affects since mediawiki 1.18
--
On 21/01/13 09:26, Rene Horn wrote:
> Package: mediawiki
> Version: 1:1.19.3-1
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> I just installed Mediawiki, and I had created a vhost for it. I was going
> through the initial setup, and got to the end where i
Thorsten Glaser wrote:
> Does Mediawiki have an API which you can pass some
> string of HTML which will throw out all unknown or
> “unsafe” (whatever that means) tags, tidy it up to
> produce valid XHTML, and return that? Otherweise,
> I guess Suggests: php-htmlpurifier and using that
> if existent
http://www.mediawiki.org/wiki/Extension:RSS_Reader seems to live
exclusively at the wiki page, instead of being at a repository.
Injection vulnerabilities are quite common in these kind of extensions.
With a quick glance, it misses to escape the output everywhere.
Just edit the page when fixing t
Niels Thykier wrote:
> Hi,
>
> I noticed a couple of changes I don't remember seeing in the diff sent
> to the list. Namely,
> * debian/patches/bz29635.patch
> * debian/patches/fix_invalid_xhtml.patch
> * debian/control (dependency update)
>
>
> Nor are these mentionen in the changelog. If
>From which version were you updating to 1:1.18.1-1?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 13/09/12 18:01, Moritz Muehlenhoff wrote:
> On Fri, Aug 31, 2012 at 06:34:38PM +0200, Julien Cristau wrote:
>> On Fri, Aug 31, 2012 at 10:37:25 +0200, Thorsten Glaser wrote:
>>
>>> The Release Notes say that 1.19.2 is a security-fix release,
>>> and does not list any unrelated changes. Question
Thorsten Glaser dixit:
> src:mediawiki contains embedded code copies of jQuery as well
> as its extensions Effects, Tipsy and UI. These are shipped in
> the mediawiki binary package, and at least three of those four
> are otherwise available in Debian:
> • libjs-jquery
> • libjs-jquery-tipsy
> • li
On 26/07/12 20:32, Thorsten Glaser wrote:
> Platonides dixit:
>
>> Thorsten, how do you expect to handle it?
>
> Have not investigated it yet. Same as with the other occurrences,
> I guess – cut off the convenience copies of third-party code, patch
> the code to use t
Thorsten, how do you expect to handle it?
MediaWiki wouldn't be affected by the web server problems with symlinks
mentioned in bug 680080#25, but there could be issues with open_basedir
setups if php is not allowed to read /usr/share/javascript/
There's of course the risk of something breaking, un
On 11/07/12 09:38, Thorsten Glaser wrote:
>> b) MediaWiki resourceloader will automatically minify the javascript
>> sent to the user. It doesn't need (nor should) be preminified.
>
> That doesn’t have anything to do with what’s in the Debian
> binary packages of the various ECMAscript libraries,
How does json-js block mediawiki-extensions?
Please note that:
a) MediaWiki ships with a copy of jQuery since 1.17
b) MediaWiki resourceloader will automatically minify the javascript
sent to the user. It doesn't need (nor should) be preminified.
--
To UNSUBSCRIBE, email to debian-bugs-dist-r
On 30/06/12 21:14, Uwe Steinmann wrote:
>> The update doesn't modify your LocalSettings.php (much less to a
>> config that will break the update!). Looking at the code, in 1.15
>> a setting of CACHE_ACCEL was silently ignored if there was no
>> accelerator cache available. Since the r83140 rewrite
On 30/06/12 14:45, Uwe Steinmann wrote:
> On Sat, Jun 30, 2012 at 12:23:44AM +0200, Platonides wrote:
>> MediaWiki doesn't require APC. Did the configuration of the wiki
>> being updated have a parameter set to "use APC"? (usually with
>> CACHE_ACCEL)
> N
On 29/06/12 20:36, steinm wrote:
> Package: mediawiki
> Version: 1:1.19.1-1
> Severity: important
>
> Dear Maintainer,
>
> i could not update to 1.19 unless I installed php-apc. After installing
> it the update.php script run without errors. The application didn't run
> either but after restartin
On 17/06/12 17:01, Luk Claes wrote:
> Package: mediawiki
> Severity: important
> Tags: security
>
> Hi,
> the following CVE (Common Vulnerabilities & Exposures) id was
> published for mediawiki.
>
> CVE-2012-2698
>
> If you fix the vulnerability please also make sure to include the
> CVE id in y
18 matches
Mail list logo
