default PPAs to HTTPS

Bug #1473091 reported by Bryan Quigley on 2015-07-09
46
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

All PPAs should default to HTTPS:
This would eventually enable us to enforce HTTPS through all of launchpad.net 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

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 ppa.launchpad.net entirely.

Changed in launchpad:
importance: Undecided → Low
status: New → Triaged
tags: added: ppa security soyuz-publish
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 "http://ppa.launchpad.net/yubico/stable/ubuntu 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?

Colin Watson (cjwatson) wrote :

It would require deciding on and acquiring a suitable domain for this that isn't under launchpad.net (compare e.g. launchpadlibrarian.net, which exists for the same reason), since otherwise an XSS attack by user-supplied content on ppa.launchpad.net would be able to steal cookies from its launchpad.net superdomain. We're currently saved by the Secure attribute, but that would become ineffective if ppa.launchpad.net 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 www.launchpad.net 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.

Bob Freeman (bobfreeman) wrote :

It seems like all the package files are already on launchpadlibrarian.net through https, eg https://launchpad.net/~fnu/+archive/ubuntu/main-fnu/+files/libcurl3_7.36.0-1fnu0~trusty_amd64.deb which redirects to https://launchpadlibrarian.net/173431189/libcurl3_7.36.0-1fnu0~trusty_amd64.deb

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

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.

Alex N. (a-nox) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers