Mirrorbrain itself doesn't support https so this will cause parts of it to fail. Running the mirror prober or scanner should make this show up.

This will need to be reverted.

In terms of getting this sorted, what sort of priority are we looking at here?

For your information: I've contacted Peter (MirrorBrain). He has shifted his attention to his private life and probably won't work on MirrorBrain anymore. So new features like https should not be expected from him. Though I saw some bits on their mailinglist about https too.

Overall we might want to keep our eyes on alternatives of MirrorBrain to distribute stuff. I dont expect that to be easy as it should be an almost drop in replacement. Maybe someone will take over MirrorBrains maintainership...

That explains why Mirrorbrain hasn't moved much in recent times...

One thing I have been considering is whether we just make use of CDN77 for both download.kde.org and files.kde.org. This would guarantee the ability of us to provide HTTPS to everyone (and even make it mandatory should we wish) as well as probably delivering a better experience to users who are in areas less well served by mirrors. It would also solve the issue of certain file types being served with the wrong mimetypes (like with Appimages and Windows MSI installers) because we would have full control, as well as ensuring we don't have issues with the increasing number of broken programs out there that have no concept of and cannot handle redirects (like the F-Droid store).

As a downside though it would mean we would no longer make use of the mirrors, and people in areas which are well served by mirrors (such as Europe and North America) will probably see a drop in performance (because CDN77 has to fetch the file from us rather than serving it from local storage). Those in areas not well served by CDN77 (primarily mainland China) would definitely be hit hard by this (apparently the Great Firewall kills download speeds). It would also mean we're dependent on a donated service from a single vendor (although we're already dependent on them with archive.neon.kde.org, and it's traffic is probably larger than download and files combined) rather than our current approach of being dependent on a larger number of indepdendent mirrors.

We could always look into whatever system it is that Debian is using to drive their redirector these days - they seem to have one now, and I don't think it's Mirrorbrain.

It's probably worth noting that it's possible that someone from the SUSE Infrastructure team will pick up maintenance of Mirrorbrain at some point, as they're heavily reliant on it for download.opensuse.org - although whether we'll see improvements like HTTPS as a result of that is another question.

Thanks for taking the time to respond. I've done some digging. Debian has been using different systems in the past: https://wiki.debian.org/DebianGeoMirror

The one powering it now is based on Fastly / Cloudfront (amazon). Which is (from what i can see) similar to a CDN like CDN77. Basically a reverse proxy, so https would not be a problem, but an insult to our current list of mirrors. Not a path we should take. Not sure what the historical reasons are to depend on it for archive.neon.kde.org, but ok.

I've poked around a bit finding alternatives, and the best thing I can find is MirrorBits. https://github.com/etix/mirrorbits
I see recent commits in their repo, they have support for https, and ipv6 (both of that we don't have) and they have some nice statistics:

• https://get.videolan.org/vlc/2.2.4/win32/vlc-2.2.4-win32.exe?mirrorlist

It gives a list of mirrors and the distance to it and a map
Also note that the url is almost the same as our setup currently is, so we should be able to make it a drop in replacement.

https://get.videolan.org/?mirrorstats
Gives an overview of the mirrors and their state.

Anyhow, if wanted I could set it up somewhere parallel to the current setup and see how it works for us.

I've also sent out some emails to other projects asking what they are using.

Cool, nice to know we have some options. Mirrorbits looks pretty good, let's see what other projects say before we start an evaluation (it looks pretty good and would definitely be a decent replacement of Mirrorbrain)

I agree that we should ideally not switch to relying on a commercial CDN where possible.

We ended up having to use CDN77 for archive.neon.kde.org because the https support in apt doesn't support redirects (despite their http support doing so, guess that's a totally different codebase...). Because download.kde.org and files.kde.org both enforce use of HTTPS now we therefore couldn't use them to deliver Neon's archives.

[spam comment removed by sysadmin]

I think we lack resources to work on this, especially also since there is no real alternative that brings substantial improvements.
I suggest we close this for now with wontfix status.

I concur with Tom on this one. We currently have a number of projects underway (most importantly, the Gitlab migration) which our resources are probably better directed towards.