Upcoming APT cryptography changes for 24.04.1

[Robie Basak]

To clarify my opinion, I should add that for LTS purposes, I think it's
important that we have a path to "ratchet up" the minimum ciphersuite
standard, and therefore it's appropriate to do in SRU as a policy.
Theoretically this would be for any release, including past releases,
and future ratchets that we might decide are appropriate after later
releases have been around a while.

But we do want to avoid user suprise and where possible do it with
plenty of notice, so it would be preferable for the actual mechanism to
support this as well as is possible.

On Tue, Jul 30, 2024 at 05:27:20PM +0900, Julian Andres Klode wrote:
> 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"
> +            ]
>          }

What I intended in my suggestion was the following. Some of this you
were already doing, but for completeness of my logic I'm listing all of
the bits that I think are important:

1. Make the change a configuration item that can be dropped into a .d/
directory.

2. The configuration should include a date from which it will happen, so
that apt does it dynamically without any further configuration on the
flag day.

3. Prior to that date, apt would know it's coming and could then display
a warning indicating that it is configured to change from that date.

And then there would be a path to making this enforced sooner for fresh
installs for .1, but eventually converging with those who have installed
.0, if that's what we choose to do.

The key thing is that then we can warn users in advance, and users would
also be able to bump the date and/or manually override to avoid the
"ratchet" entirely, without being surprised by interruption of service
and frantic searching to mitigate an issue after it has affected them.

Ideally, if apt could expose the configuration file and line number that
results in this bump, then a user would even be able to immediately see
and bump the date without even having to look up the syntax.

But I think in your example above the message relates to what would be
displayed after it has happened, not before?

Julian, you mentioned a concern that the date might need to change for
security reasons. But I think that's OK - we should just word the
warning appropriately: "...on <date> but may change earlier if the
security environment changes sooner".

I'm not sure if I've misunderstood. Corrections welcome! The key point
of my suggestion was that from the user's perspective, for
already-installed systems, they get a clear warning of an upcoming
ratchet, and can postpone or cancel it in advance by just changing
configuration, rather than having to wait for an update that they then
need to adjust.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20240730/b485e984/attachment.sig>