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).
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 by your own
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
--
To
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 it
tries
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
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,
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 they were
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 is, (to
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, which
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,
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 the system-wide copy, and kick
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
•
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
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)
Now that you mentioned it, I checked the configuration
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 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 restarting apache
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 your
18 matches
Mail list logo
