default PPAs to HTTPS

Bug #1473091 reported by Bryan Quigley
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Colin Watson

Bug Description

All PPAs should default to HTTPS:
This would eventually enable us to enforce HTTPS through all of domain.
It will give us more data on serving packages over HTTPS. (for possible archive consideration far down the line)
A user using a PPA is giving out more information to networks they are on about their system configuration. If we switch to https, all that network admins can know is that they are using a PPA.

CVE References

Revision history for this message
William Grant (wgrant) wrote :

This is non-trivial due to the arbitrary content served on the domain. We would do better to move it away from entirely.

Changed in launchpad:
importance: Undecided → Low
status: New → Triaged
tags: added: ppa security soyuz-publish
Revision history for this message
Peter Eckersley (pde-lists) wrote :

Right now, PPAs don't even support HTTPS at all (I just tried to switch an APT entry pointing to " xenial main" over to HTTPS, and got a 404)?

What would it take to at least serve a copy of the HTTP content, over HTTPS?

Revision history for this message
Colin Watson (cjwatson) wrote :

It would require deciding on and acquiring a suitable domain for this that isn't under (compare e.g., which exists for the same reason), since otherwise an XSS attack by user-supplied content on would be able to steal cookies from its superdomain. We're currently saved by the Secure attribute, but that would become ineffective if were served over HTTPS. It would of course then require reconfiguring various things to point to that, and I would expect quite a bit of miscellaneous fallout; it's the sort of task that requires budgeting a lot of time for debugging.

(The alternative would be moving the main webapp to a subdomain such as and resetting all session cookies, but that's much more work and I think that ship has long since sailed.)

The usual strategy of redirecting HTTP to HTTPS may or may not be a good idea here, as the client situation isn't the same as with browsers. apt gained support for following redirects in 2009, which is long enough ago that we can probably assume it's present, but it's also configurable and it's hard to know how many people will have disabled it.

As illustrated by comment #2, people will probably expect to just be able to switch the scheme and not the host. It's possible that we could safely have an HTTPS virtual host that just redirects everything to whatever the new domain is.

Revision history for this message
Bob Freeman (bobfreeman) wrote :

It seems like all the package files are already on through https, eg which redirects to

So isn't it just a case of changing the urls in the relevant file in /etc/apt/sources.list.d/ ?

Revision history for this message
Colin Watson (cjwatson) wrote :

Bob, I'm afraid not, because (a) that doesn't include the indexes that apt uses to find those files, and (b) the librarian stores files in a generic layout which isn't directly suitable for apt.

Revision history for this message
Alex N. (a-nox) wrote :

CVE-2019-3462 puts this topic back into focus. It would be great to have PPAs support https.

Revision history for this message
Piero Filippin (thedayofcondor) wrote :

I (barely) understand the XSS issue - is this because all the subdomains share the certificate vs having a different certificate per subdomain?

I assume the latter is not an option because of the sheer volume of certificates required...

Revision history for this message
Colin Watson (cjwatson) wrote :

No, it has nothing to do with certificates.

Launchpad needs to set the domain of its session cookies to "" so that they're visible by its other virtual hosts (,, etc.), but this also causes them to be visible to all other subdomains of We also set the "secure" flag on those cookies, which mitigates this by ensuring that browsers at least only send them over HTTPS. However, if were accessible over HTTPS, then any page there would be able to exfiltrate your session cookie. While I don't currently know of a way to get to serve arbitrary content with Content-Type: text/html, it's a service that hosts a great deal of user-generated files, and it wouldn't take that much to construct abuses of it that would confuse browsers. We need to move it before using HTTPS is safe.

Revision history for this message
Daniel Tammeling (danieltammeling) wrote :

Using apt with http returns a "500 software caused connection abort" error when going through Sophos XG, but work well when going through https. Until launchpad supports https, I'm stuck using the inferior, slow, and slow to update https mirrors sparsely scattered throughout the internet.

Revision history for this message
Colin Watson (cjwatson) wrote :

I've filed (internal link only) asking our sysadmins to register another domain so that we can start making progress on this.

Revision history for this message
Colin Watson (cjwatson) wrote :

The alternate domain in question has been registered, and I've filed (again, internal link only) to get it configured on the relevant host.

Revision history for this message
Colin Watson (cjwatson) wrote : and now exist, and are both HTTPS-capable. It's possible to use today in place of in sources.list.

We still have some work to do to make the Launchpad UI default to this, as well as tools like add-apt-repository.

Changed in launchpad:
status: Triaged → In Progress
assignee: nobody → Colin Watson (cjwatson)
Revision history for this message
Colin Watson (cjwatson) wrote :

The Launchpad web UI now advertises the new URLs (and for private PPAs). As previously mentioned, the old URLs will also continue working indefinitely.

I've filed bug 1959015 for the add-apt-repository changes.

Changed in launchpad:
status: In Progress → Fix Released
Changed in launchpad:
assignee: Colin Watson (cjwatson) → Le dao giang (giangprosite)
Colin Watson (cjwatson)
Changed in launchpad:
assignee: Le dao giang (giangprosite) → Colin Watson (cjwatson)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.