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 -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
