Upcoming APT cryptography changes for 24.04.1

Julian Andres Klode julian.klode at canonical.com
Mon Jul 15 18:31:13 UTC 2024


Hello!

As you all know, and the release notes state, we want to promote
the weak public key algorithms in APT from warnings to errors for
the upcoming 24.04.1 release to ensure people _actually_ get a
security benefit.

Now warnings provide some advantage already as you can see weak
repositories; but they do not provide full safety: If a repository
has multiple keys configured, but only signs with safe ones, you
do not get a warning, but an attacker could downgrade the key.

This was skipped for the main 24.04 release as PPAs had not been
resigned yet, but the resigning is at the final stages now, and
having the final policy in place for 24.04.1 means that all those
upgrades from 22.04 and new installs from the new media get the
safe experience.

Some repositories have been inadvertently affected by the way this
was implemented as we also revoked ECC curves other than Ed25519
and Ed448, such as NIST P-256; raising this to errors now would
break those users entirely which is not intended.

To mitigate risk my plan is:

1. Introduce new apt 2.8.1 release that will add the other
   256-bit or stronger curves to the allowed list. It will
   also introduce new levels for warnings and audit messages
   to ensure that you still get warnings for unusual curves,
   and audit messages going forward.

   See https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2073126 for
   more details.

   I have asked foundations and ubuntu security for a review
   of this change.

2. Once the PPAs have been switched to the 4096-bit RSA key,
   issue a message to apt users using the Pro client 'apt-news'
   mechanism on 24.04 stating that:

   > All PPAs have been resigned with 4096-bit keys now, and support for old
   > signing keys will be disabled starting August 05. If apt update lists
   > any affecteds PPAs, please use add-apt-repository -r to remove them
   a> nd re-add them again.

   (or similar wording)

   A similar message can be issued for older releases so they
   can upgrade their security, however I have not yet checked
   if it actually removes the key from trusted.gpg.d back then.

3. Optionally, release an update for software-properties that
   refreshes the signing key for affected PPAs in postinst. This
   will catch everyone who is online and did not see the message.

   We can use the remove & re-add logic here, but it may be more
   suitable to just replace exactly the key in the file which can
   be done with a little bit of apt_pkg.TagSection.write() :)

   Figuring out which PPAs need a key refresh is a bit annoying,
   essentially it boils down to looking at all configured PPAs,
   calling gpgv on their release files with a ">=rsa2048" assertion
   and see if it passes it or not.

   While the benefits are clear; it is important to note that key
   refresh is almost TOFU: The only integrity assurance we have about
   the authenticity of the new key is launchpad's https certificate,
   so it is worth considering if this is something we feel comfortable
   about doing automatically.

4. Release the apt update to the -updates pocket on August 05, override
   the phasing to 0% and build images with that. This ensures that new
   installs have the new policy enabled. Note that there's some policy
   about not including phased updates in images that will have to be
   temporarily lifted.

   Also do note that phasing is ignored in chroots due to image
   building concerns, so some use cases will still see the update.

5. Slowly phase the apt update. It seems fine to roll this out
   over a long time frame such as 3 months assuming there are
   no other upcoming urgent apt updates.

   I do not know how much control we have over the phasing speed.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en



More information about the Ubuntu-release mailing list