blog.launchpad.net Open in urlscan Pro
2620:2d:4000:1::2a  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Log in



LAUNCHPADBLOG

0


NEW DOMAIN NAMES FOR PPAS

Published by Colin Watson February 16, 2022 in PPA



Since they were introduced in 2007, Launchpad’s Personal Package Archives (PPAs)
have always been hosted on ppa.launchpad.net. This has generally worked well,
but one significant snag became clear later on: it was difficult to add HTTPS
support for PPAs due to the way that cookies work on the web.

Launchpad uses a cookie for your login session, which is of course
security-critical, and because we use multiple domain names for the main web
application (bugs.launchpad.net, code.launchpad.net, and so on), the session
cookie domain has to be set to allow subdomains of launchpad.net. We set the
“Secure” flag on session cookies to ensure that browsers only ever send them
over HTTPS, as well as the “HttpOnly” flag to prevent direct access to it from
JavaScript; but there are still ways in which arbitrary JS on an HTTPS subdomain
of launchpad.net might be able to exfiltrate or abuse users’ session cookies. As
a result, we can never allow any HTTPS subdomain of launchpad.net to publish
completely user-generated HTML that we don’t process first.

We don’t currently know of a way to get ppa.launchpad.net to serve arbitrary
HTML as Content-Type: text/html, but this is quite a brittle protection as there
are certainly ways (used for things like installer uploads) to upload arbitrary
files to ppa.launchpad.net under a user-controlled directory structure, and we
don’t want the webapp’s security to depend on nobody figuring out how to
convince a browser to interpret any of that as arbitrary HTML. The librarian is
already on a separate launchpadlibrarian.net domain name for a similar reason.

To resolve this dilemma, we’ve added a new ppa.launchpadcontent.net domain name
which supports both HTTP and HTTPS (and similarly
private-ppa.launchpadcontent.net for private PPAs, which as before is
HTTPS-only). add-apt-repository in Ubuntu 22.04 will use the new domain name by
default.

The old names will carry on working indefinitely – we know they’re embedded in
lots of configuration and scripts, and we have no inclination to break all of
those – but we recommend moving to the new names where possible.
ppa.launchpad.net will remain HTTP-only.

Some systems may need to be updated to support the new domain name, particularly
things like HTTP(S) proxy configuration files and no_proxy environment
variables.



--------------------------------------------------------------------------------

0


COMMENT EDITING IS NOW POSSIBLE

Published by Thiago F Pappacena May 28, 2021 in General



It took a while, but now Launchpad finally allows users to edit their comments
on questions, bug reports and merge proposal pages.

The first request for this feature dates back from 2007. Since then, Launchpad
increased a lot in terms of new features, and the other priorities took
precedence over that request, but the request was still more than valid. More
recently, we managed to bump the priority of this feature, and now we have it:
users are now allowed to edit their comments on Launchpad answers, bugs and
merge proposals!

This has been available in the API for a few days already, but today we finally
released the fresh new pencil icon in the top-right corner of your messages.
Once you click it, the message is turned into a small form that allows you to
edit your message content.

For messages that were edited before, it is possible to see old versions of that
edited message by clicking the “last edit …” link, also at the top of the
message.

In case you introduce sensitive information by mistake in your comment and need
to remove it from the message history after editing it, you can always use the
API to do so. We plan to add a remove button to the message’s revision history
UI soon, to make this work easier.

The Launchpad team is proud of this new feature, and we hope that it will be
useful for everyone! Let us know if you have any feedback!



--------------------------------------------------------------------------------

0


GIT PROTOCOL V2 AVAILABLE AT LAUNCHPAD

Published by Thiago F Pappacena September 28, 2020 in Code, Performance



After a few weeks of development and testing, we are proud to finally announce
that Git protocol v2 is available at Launchpad! But what are the improvements in
the protocol itself, and how can you benefit from that?

The git v2 protocol was released a while ago, in May 2018, with the intent of
simplifying git over HTTP transfer protocol, allowing extensibility of git
capabilities, and reducing the network usage in some operations.

For the end user, the main clear benefit is the bandwidth reduction: in the
previous version of the protocol, when one does a “git pull origin master”, for
example, even if you have no new commits to fetch from the remote origin, git
server would first “advertise” to the client all refs (branches and tags)
available. In big repositories with hundreds or thousands of refs, this simple
handshake operation could consume a lot of bandwidth and time to communicate a
bunch of data that would potentially be discarded by the client after.

In the v2 protocol, this waste is no longer present: the client now has the
ability to filter which refs it wants to know about before the server starts
advertising it.

The v2 protocol is not the default on git clients yet, but if you are using a
git version higher than 2.19, you can use v2: simply run git config --global
protocol.version 2, and you will be using the most recent protocol version when
communicating with servers that support this version. Including Launchpad, of
course.

And even if you have repositories hosted in a server that is not yet compatible
with v2, don’t worry: the git client is backward compatible. If the server does
not support v2, git client should fall back gracefully to the previous version
and everything should continue to work as expected. We hope you enjoy the new
feature. And let us know if you have any feedback!



--------------------------------------------------------------------------------

0


LOGIN REGRESSION FOR USERS WITH NON-ASCII NAMES

Published by Colin Watson August 20, 2020 in General



On 2020-08-13, we deployed an update that caused users whose full names contain
non-ASCII characters (which is of course very common) to be unable to log into
Launchpad. We heard about this serious regression from users on 2020-08-17, and
rolled out a fix on 2020-08-18. We’re sorry about this; it doesn’t meet the
standards of both inclusion and quality that we set for ourselves. This post
aims to explain what happened, technical details of why it happened, and the
steps we’ve taken to avoid it happening again.

Read the rest of this entry »



--------------------------------------------------------------------------------

1


BUG EMAILS NOW USE THE BUG’S ADDRESS IN THE FROM: HEADER

Published by Colin Watson May 20, 2020 in Notifications



The From: addresses used by Launchpad’s bug notifications have changed, to
improve the chances of our messages being delivered over modern internet email.

Launchpad sends a lot of email, most of which is the result of Launchpad users
performing some kind of action. For example, when somebody adds a comment to a
bug, Launchpad sends that comment by email to everyone who’s subscribed to the
bug.

Most of Launchpad was designed in an earlier era of internet email. In that era,
it was perfectly reasonable to take the attitude that we were sending email on
behalf of the user – in effect, being a fancy mail user agent or perhaps a
little like a mailing list – and so if we generated an email that’s a direct
result of something that a user did and consisting mostly of text they wrote, it
made sense to put their email address in the From: header. Reply-To: was set so
that replies would normally go to the appropriate place (the bug, in the case of
bug notifications), but if somebody wanted to go to a bit of effort to start a
private side conversation then it was easy to do so; and if email clients had
automatic address books then those wouldn’t get confused because the address
being used was a legitimate address belonging to the user in question.

Of course, some people always wanted to hide their addresses for obvious privacy
reasons, so since 2006 Launchpad has had a “Hide my email address from other
Launchpad users” switch (which you can set on your Change your personal details
page), and since 2010 Launchpad has honoured this for bug notifications, so if
you have that switch set then your bug comments will be sent out as something
like “From: Your Name <bug-id@bugs.launchpad.net>“. This compromise worked
tolerably well for a while.

But spammers and other bad actors ruin everything, and the internet email
landscape has changed. It’s reasonably common now for operators of email domains
to publish DMARC policies that require emails whose From: headers are within
that domain to be authenticated in some way, and this is incompatible with the
older approach. As a result, it’s been getting increasingly common for Launchpad
bug notifications not to be delivered because they failed these authentication
checks. Regardless of how justifiable our notification-sending practices were,
we have to exist within the reality of internet email as it’s actually deployed.

So, thanks to a contribution from Thomas Ward, Launchpad now sends all its bug
notifications as if the user in question had the “Hide my email address from
other Launchpad users” switch set: that is, they’ll all appear as something like
“From: Your Name <bug-id@bugs.launchpad.net>“. Over time we expect to extend
this sort of approach to the other types of email that we send, possibly with
different details depending on the situation.

Please let us know if this causes any strange behaviour in your email client. We
may not be able to fix all of them, depending on how they interact with DMARC’s
requirements, but we’d like to be aware of what’s going on.





--------------------------------------------------------------------------------

1


LAUNCHPAD NEWS, MARCH 2019 – JULY 2019

Published by Colin Watson August 6, 2019 in General



Here’s a brief changelog of what we’ve been up to since our last general update.

Read the rest of this entry »



--------------------------------------------------------------------------------

0


LAUNCHPAD NEWS, FEBRUARY 2019

Published by Colin Watson March 7, 2019 in General



Here’s a brief changelog for this month.

Read the rest of this entry »



--------------------------------------------------------------------------------

0


LAUNCHPAD NEWS, JULY 2018 – JANUARY 2019

Published by Colin Watson February 21, 2019 in General



Here’s a brief changelog of what we’ve been up to since our last general update.

Read the rest of this entry »



--------------------------------------------------------------------------------

0


GIT PER-BRANCH PERMISSIONS

Published by Colin Watson January 10, 2019 in Code



We’ve had Git hosting support in Launchpad for a few years now. One thing that
some users asked for, particularly larger users such as the Ubuntu kernel team,
was the ability to set up per-branch push permissions for their repositories.
Today we rolled out the last piece of this work.

Launchpad’s default behaviour is that repository owners may push anything to
their own repositories, including creating new branches, force-pushing
(rewriting history), and deleting branches, while nobody else may push anything.
Repository owners can now also choose to protect branches or tags, either
individually or using wildcard rules. If a branch is protected, then by default
repository owners can only create or push it but cannot force-push or delete; if
a tag is protected, then by default repository owners can create it but cannot
move or delete it.

You can also allow selected contributors to push to protected branches or tags,
so if you’re collaborating with somebody on a branch and just want to be able to
quickly pair-program via git push, or you want a merge robot to be able to land
merge proposals in your repository without having to add it to the team that
owns the repository and thus give it privileges it doesn’t need, then this
feature may be for you.

There’s some initial documentation on our help site, and here’s a screenshot of
a repository that’s been set up to give a contributor push access to a single
branch:



--------------------------------------------------------------------------------

0


LAUNCHPAD NEWS, JUNE 2018

Published by Colin Watson July 6, 2018 in General



Here’s a brief changelog for this month.

Read the rest of this entry »



--------------------------------------------------------------------------------

Previous Entries


LATEST POSTS

 * New domain names for PPAs
 * Comment editing is now possible
 * Git Protocol v2 Available at Launchpad
 * Login regression for users with non-ASCII names
 * Bug emails now use the bug’s address in the From: header

Terms of use | Help improve Launchpad | FAQ

Launchpad Blog by Canonical Ltd is licensed under a Creative Commons Attribution
2.0 UK: England & Wales License.

© 2004-2019 Canonical Limited.