Upcoming APT cryptography changes for 24.04.1

[Julian Andres Klode]

On Mon, Jul 15, 2024 at 08:31:13PM GMT, Julian Andres Klode wrote:
> 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.

After consulting with Robie I have added an additional mitigation;
if you upgrade from 2.7.14 in the release pocket (or older 2.7.x
from the devel series), the apt.postinst creates a new file

/etc/apt/apt.conf.d/00-temporary-rsa1024

Which temporarily downgrades weak RSA keys to warnings again;
this allows us to decouple rolling out the new enforcement to
new installs from rolling out the enforcement to existing systems,
mitigating the risk for regressions.

We can then work to migrate existing systems to stronger keys
(semi?)automatically following the point release until the next
point release at which point we should release an apt that deletes
that mitigation file again.

> 
> 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.

The wording needs to be shorter such that it can fit on 2 lines
and have a URL link in the 3rd line.

One option could be:

+        {
+            "begin": "2024-08-05T00:00:00Z",
+            "lines": [
+                "All PPAs are now dual signed with 4096-bit RSA keys.",
+                "Remove and readd PPAs to migrate to the new keys.",
+                "For more details see: https://ubuntu.com/blog/ubuntu-ppa-resigning"
+            ]
         }

Though it's arguably nicer to not include instructions there
and move them to the blog post (and or only share instructions
once we have automatic tooling)

> 
> 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.

This is obsolete now due to the added apt.conf.d mitigation.

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