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.
It would require deciding on and acquiring a suitable domain for this that isn't under launchpad.net (compare e.g. launchpadlibrar ian.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.