Repository hosting services' HTTPS support - things are getting much better for criterion sites_https

David A. Wheeler

As you know, most OSS projects today use a repository hosting service (aka "forge"), GitHub being the most popular. This means that many OSS projects have had trouble meeting criterion "sites_https" because of HTTPS support limitations in their repo hosting service.

We *could* drop the criterion sites_https, but there's general agreement that this is a *valid* criterion. After all, HTTPS provides a simple widely-understood mechanism that counters many attacks. We just need to get more repo hosting services to support HTTPS more broadly so that more projects can easily support HTTPS.

We have a lot of good news on this point. Here's the status as I understand it:
* GitHub: GitHub pages added HTTPS support for non-custom domains earlier in 2016. For custom domains we'll accept the CDN workaround, which reduces that barrier as well. Some details: and
* GitLab (Community edition): Their community edition has HTTPS support for GitLab pages per an announcement in December 2016. See: and .
* SourceForge: SourceForge's project websites now support HTTPS, per this December 2016 announcement:
* Savannah: Project pages yes, repo version control no, though the latter is expected to be fixed. This is a problem, e.g., this is the only thing keeping GNU Make from getting a badge. Oddly enough, this means that Savannah (a GNU project) fails the GNU project's own repo criteria (C6 in ); this appears to have been a total oversight. This problem was reported to Savannah on June 2016 at . Savannah is now committed to getting HTTPS working for version control information per this email from 2016-11-23: . My thanks to John Sullivan (Executive Director, Free Software Foundation) for confirming this. We'll just keep pressing for this to get done.

There are certain to be some teething problems and odd narrow limitations (e.g., on GitHub your username & groupname can't include a "." - a limitation that will affect few people). Still, this is a *lot* of progress. At this point I have no plans to drop criterion sites_https, and instead, I plan to encourage lagging hosting services to improve HTTPS support and to confirm that the "CDN workaround" for custom domains on GitHub pages is fine for meeting sites_https.

I've been doing some nudging for some of these cases, some of it behind-the-scenes, but it's the people who made these changes actually *happen* that get the credit. My sincere thanks to all of them!

--- David A. Wheeler