wmts.dabpunkt.eu does resolv here. The other links are down at the moment (had to switch the server) and will be back soon.

@TheDJ: I see. Now I begin to understand why the WMF never handles the important stuff: Nobody cares about the important stuff, so it is marked as “low”, and because it is marked as “low”, nobody cares about it.

@Krenair: If it would be a vulnerabilitiy, the priority would be “high” if I’m not mistaken. I asked why this was lowered from “normal” to “low”, while it asks for an improvment in a security relevant area. In my eyes such a request should have a higher priority than an cat-image-generator.

Why was a security-relevant-task marked as “low”?

In T142944#2560827, @hoo wrote:

For this, we also desire to get the placeholders into search engines, to drive more traffic to those small Wikipedias (which don't have much content on their own, thus few search engine traffic).

May I ask how this should work? As far as I understand your special-page generates an “article” from wikidata-data if there is no real article. So if for example there would be no article about “Horse” on english Wikipedia if someone would search for “Horse” your special-page would generate it.
But how can you feed that to a external search-engine? For that the search-engine would need to ask for a page that is not there– why should it do so and for which articles should it ask?

mm, but the search-continue-attribute is only working until you reach the limit of 50.

In T140536#2474949, @Peachey88 wrote:

@DaBPunkt Do you know if the original thumbs before the first delete exhibited the black lines?

Forgot to mention: I tried to purge the pictures already.

@akosiaris: That the from-address is invalid (as: not usable) is just the reason that the displaying of the sender-field would a good idea (BTW: The OTRS knows that the from is invalid – when you try to reply to it).

Cool, thanks :-).

I just checked my shell-log:

15:22:25dab@dabpc:/tmp$ optipng -o7 dewiki-2x.png 
** Processing: dewiki-2x.png
270x310 pixels, 4x8 bits/pixel, RGB+alpha
Input IDAT size = 54341 bytes
Input file size = 54544 bytes

In T132792#2212182, @Dereckson wrote:

Optipng

@Urbanecm When you add or replace static/ files, run optipng -o7 on each file to optimize them. See http://optipng.sourceforge.net/. I've done it here in PS4.

@Dereckson Yes, thanks for catching.

While it’s trivial, following the patch for the InitialiseSettings (I patched against HEAD).

--- InitialiseSettings.php.org  2016-04-15 17:27:32.000000000 +0200
+++ InitialiseSettings.php      2016-04-15 17:29:51.074026181 +0200
@@ -1130,6 +1130,7 @@
        //'cswiki' => array( '1.5x' => '/static/images/project-logos/cswiki-1.5x.png', '2x' => '/static/images/project-logos/cswiki-2x.png' ), // T130392
        'enwiki' => array( '1.5x' => '/static/images/project-logos/enwiki-1.5x.png', '2x' => '/static/images/project-logos/enwiki-2x.png' ),
        'dawiki' => array( '1.5x' => '/static/images/project-logos/dawiki-1.5x.png', '2x' => '/static/images/project-logos/dawiki-2x.png' ), // T131033
+       'dewiki' => array( '1.5x' => '/static/images/project-logos/dewiki-1.5x.png', '2x' => '/static/images/project-logos/dewiki-2x.png' ), // T132792
        'fawiki' => array( '1.5x' => '/static/images/project-logos/fawiki-1.5x.png', '2x' => '/static/images/project-logos/fawiki-2x.png' ),
        'frwiki' => array( '1.5x' => '/static/images/project-logos/frwiki-1.5x.png', '2x' => '/static/images/project-logos/frwiki-2x.png' ),
        'ilowiki' => array( '1.5x' => '/static/images/project-logos/ilowiki-1.5x.png', '2x' => '/static/images/project-logos/ilowiki-2x.png' ),

In T91504#1996450, @Dzahn wrote:

https://www.ssllabs.com/ssltest/analyze.html?d=ticket.wikimedia.org grade A

@DaBPunkt i would like to claim this is resolved. All the main things you listed when this was created have been addressed meanwhile.

Question: Is there a page to test the new version? Because at https://lizenzhinweisgenerator.wmflabs.org/ it is still wrong.

Sorry, that was my mistake. User-Agent-overwriting-plugin was active and so the browser reported IE6 (which is indeed very old). Sorry again.

In T117362#1836062, @Krenair wrote:

See @Aklapper's comment.

In T117362#1835493, @Krenair wrote:

@DaBPunkt: Ping. This ticket is unlikely to progress without your input. Also, is this problem actually specific to commons?

In T117362#1772198, @Aklapper wrote:

While it is definitively a bad idea to send HTML-emails in general: MIME is not another email-format. It’s a way to define blocks in emails. These blocks can be plain-text, html, images, signatures, attachments and so on.

I think “mid” should be enough for this case.

Partly solved with version 0.10

In T108579#1524034, @BBlack wrote:

@DaBPunkt can you provide details on the client software (browser version, OS version, etc?) and any local software that might be interfering ("antivirus" sorts of things that might intercept browser connections)?

In T88242#1462658, @Krenair wrote:

So, my understanding of this is that you can upload .dia files, but if they're compressed then you hit a bug in MediaWiki? If that's correct we should close this.

Erledigt mit Version 0.9.
Buttons als reine Links scheinen mit HTMl5 nicht mehr zu gehen – ich habe den Link aber mittels CSS ein button-artiges Aussehen gegeben; sie sollten nun auffallen.

In T55259#1448222, @BBlack wrote:

Done, which should get us ECDHE-based Forward Secrecy on any remaining precise+apache2.2 hosts. Tested a few in ssllabs and they look fine. sodium (lists.wikimedia.org) should be the only apache left that doesn't do FS now.

In T91504#1437522, @BBlack wrote:

In T91504#1435161, @BBlack wrote:

DNSSEC and DANE are not things we currently do.

In T55259#1424380, @Chmarkine wrote:

There are more. The strong version doesn't allow TLS 1.0, so IE < 11, Android < 4.4, Java < 8, OpenSSL < 1.0, Safari (OS X) < 7 are inaccessible.[1]

Re-opened.
Guys, Mediawiki also logs the IP-address of every users – but not every user can see the ip of other users, can’t they? My request says clearly that the log should be “HIDE”, not deleted or anything.

Re-opened.
While it is no problem that Mediawiki LOGS the data, the problem is that is SHOWS these data to everybody.

Sure @Krenair, but why do we need a community-consensus to disable something, but not one to enable something?
And if MediaWiki really have something enabled on default because somewhere in the internet someone COULD use a feature: Why not disable it in the Wikimedia-config globaly and ASK first who (=which of our wikis) could need it?

In T97766#1251873, @Krenair wrote:

In T97766#1251793, @Steinsplitter wrote:

No consensus need to switch it on, but consensus needed to switch it off. Simply a joke.

Allow me to be very clear here: This feature was added as a commit to MediaWiki, it was not a new extension. Such things which are deployed automatically on the MW train (i.e. changes to MediaWiki defaults) do not need consensus from $MY_FAVOURITE_WIKI, because otherwise we'd have Wikimedia wikis dictating MediaWiki development and affecting non-Wikimedia sites. Rights changes for specific wikis generally do.

In T90351#1215553, @Krenair wrote:

@DaBPunkt: Please respond.

Guys, while it is true that apache 2.2 doesn’t support ECHD, it supports DHE just fine. And DHE IS a PFS. I know that it is a bit slower, but does it really matter for these web-servers?

In T91504#1140476, @Matanya wrote:

SSL config supports PFS

Behoben mit rev. 163.

Sorry, I forgot to close this bug.

In T90483#1060658, @Aklapper wrote:

In T90483#1060487, @Saenger wrote:

My data belong to me, and without my explicit consent nobody must ever deal with them.

For the records, https://wikimediafoundation.org/wiki/Privacy_policy states

In T90483#1060252, @tomasz wrote:

Adding the community-consensus-needed tag as there are no links to any community discussions on the subject (at this moment).

@Aklapper: I had my mail.log open during the time; I would have seen when an email arrived. But I also checked my SPAM-folder now, and AFAIS there are no emails there too.

Was is really necessary to inform EVERY mailing-list? This is clearly a problem that only OPs can solve, not we mail-list-admins.

In T71445#1017081, @Krenair wrote:

Yes, and it's bad. It's why this ticket exists.