<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 5/3/24 22:08, Seth Arnold wrote:<br>
</div>
<blockquote type="cite" cite="mid:20240504020816.GB472174@millbarge">
<pre>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'
</pre>
</blockquote>
<p>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. </p>
<p>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. <br>
</p>
<p>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. <br>
</p>
<pre class="moz-signature" cols="72">--
David A. Desrosiers
Principal Support Engineer (PSE/DSE), Canonical US
<a class="moz-txt-link-rfc2396E" href="mailto:david.desrosiers@canonical.com"><david.desrosiers@canonical.com></a></pre>
</body>
</html>