But, I also expect very few of our users would use -proposed. What percentage do you expect? I'm guessing less than 1%. Instead of configuring proposed by default, I suggest that we should make this work: $ sudo add-apt-repository proposed Unable to handle repository shortcut 'proposed'
Let's also not lose sight of the fact that if proposed had been enabled by default with the current LTS release, the xz exposure and impact would have been a lot broader than it was, and also a lot harder to clean up and retract from.
As it was, the customer I support mirrored -proposed into their internal aptly during the Feb 28-March 30 window when the exploited versions of xz packages were resident in noble-proposed, and some of their machines had it deployed as part of internal automation. They had to go through a manual exercise to delete the pocket from their mirror and specifically the xz-utils packages for a daily span of 30 days of mirroring and resilver all of their aptly package lists to redact that and remove their own potential for exposure.
Let's err on the side of being a bit more cautious here, so we don't leave ourselves open to another possible 'adventure' that could sneak through unnoticed, before our users/customers are impacted. -proposed explicitly disabled by default has a purpose and requires being manually enabled, and once we flip that position, we may lose the value that explicit testing of packages in -proposed provides.
-- David A. Desrosiers Principal Support Engineer (PSE/DSE), Canonical US <david.desrosiers@canonical.com>
